From internet-drafts@ietf.org Fri Jul 1 18:20:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610E711E80C7; Fri, 1 Jul 2011 18:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JY1dvS3eSz8; Fri, 1 Jul 2011 18:20:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2411E807E; Fri, 1 Jul 2011 18:20:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110702012000.26274.69065.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2011 18:20:00 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-sec-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 01:20:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP-Security (LISP-SEC) Author(s) : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-sec-00.txt Pages : 20 Date : 2011-07-01 This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-sec-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-sec-00.txt From luigi@net.t-labs.tu-berlin.de Sat Jul 2 07:41:05 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0A011E811F for ; Sat, 2 Jul 2011 07:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAtiiSxvRQoc for ; Sat, 2 Jul 2011 07:41:04 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 76C5D11E80DD for ; Sat, 2 Jul 2011 07:41:03 -0700 (PDT) Received: from [192.168.2.101] (p4FC25EA5.dip.t-dialin.net [79.194.94.165]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 5376870B903A; Sat, 2 Jul 2011 16:41:01 +0200 (CEST) From: Luigi Iannone Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-597977572 Date: Sat, 2 Jul 2011 16:40:59 +0200 References: <20110702143324.1031.95238.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: <11DCF83E-E978-4703-A677-AF74CD776624@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.1084) Cc: David Meyer Subject: [lisp] Fwd: I-D Action: draft-lisp-eid-block-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 14:41:06 -0000 --Apple-Mail-23-597977572 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, the new draft for the EID block request has been submitted. Attached the WDiff w.r.t the previous version. Luigi Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 2, 2011 16:33:24 GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-lisp-eid-block-00.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : LISP EID Block > Author(s) : Luigi Iannone > Darrel Lewis > David Meyer > Vince Fuller > Filename : draft-lisp-eid-block-00.txt > Pages : 9 > Date : 2011-07-02 >=20 > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used by sites deploying LISP as EID (Endpoint IDentifier) addressing > space for local intra-domain routing and global endpoint > identification. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-23-597977572 Content-Type: multipart/mixed; boundary=Apple-Mail-24-597977572 --Apple-Mail-24-597977572 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

the new draft for the EID block request has been = submitted.

Attached the WDiff w.r.t the = previous = version.

Luigi


=
Begin forwarded message:

Date: July 2, 2011 16:33:24 GMT+02:00
Subject: I-D Action: = draft-lisp-eid-block-00.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

Title =           : LISP EID = Block
= Author(s)       : Luigi Iannone
=             &n= bsp;           &nbs= p;Darrel Lewis
=             &n= bsp;           &nbs= p;David Meyer
=             &n= bsp;           &nbs= p;Vince Fuller
Filename =        : = draft-lisp-eid-block-00.txt
Pages =           : 9
Date =            : = 2011-07-02

  This is a direction to IANA to allocate a = /16 IPv6 prefix for use
  with the Locator/ID Separation = Protocol (LISP).  The prefix will be
  used by sites = deploying LISP as EID (Endpoint IDentifier) addressing
=   space for local intra-domain routing and global endpoint
=   identification.


A URL for this Internet-Draft = is:
h= ttp://www.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt

= Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt
_= ______________________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt
= --Apple-Mail-24-597977572 Content-Disposition: attachment; filename="WDiff-02->00.html" Content-Type: text/html; x-mac-hide-extension=yes; x-unix-mode=0644; name="WDiff-02->00.html" Content-Transfer-Encoding: 7bit wdiff draft-meyer-lisp-eid-block-02.txt draft-ietf-lisp-eid-block-00-submitted.txt 

Network Working Group                                         L. Iannone
Internet-Draft                             Deutsche Telekom Laboratories
Intended status: Informational                                  D. Lewis
Expires: September 13, 2011 January 3, 2012                                        D. Meyer
                                                               V. Fuller
                                                     Cisco Systems, Inc.
                                                          March 12,
                                                            July 2, 2011

                             LISP EID Block
                   draft-meyer-lisp-eid-block-02.txt
                      draft-lisp-eid-block-00.txt

Abstract

   This is a direction to IANA to allocate a /8 /16 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP).  The prefix will be
   used by sites deploying LISP as EID (Endpoint IDentifier) addressing
   space for local intra-domain routing and global endpoint
   identification.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 13, 2011. January 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations  Rationale and Intent  . . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgments  Expected use  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations  Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Routing Considerations  . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   11. Normative References  . . . . . . . . . . . . . . . . . . . . . 6 8
   Appendix A.  Document Change Log  . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6 9

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   This memo document directs the IANA to allocate a /16 IPv6 prefix for use
   with the Locator/ID Separation Protocol (LISP - [I-D.ietf-lisp]),
   LISP Map Server ([I-D.ietf-lisp-ms]), LISP Alternative Topology
   (LISP+ALT - [I-D.ietf-lisp-alt]) (or other) mapping system, and LISP
   Interworking ([I-D.ietf-lisp-interworking]).

   This block will be used as global Endpoint IDentifier (EID) space
   (Section 3).

3.  Definition of Terms

   LISP operates on two name spaces and introduces several new network
   elements.  This section provides high-level definitions of the LISP
   name spaces and network elements. elements and as such, it MUST NOT be
   considered as an authoritative source.  The reference to the
   authoritative document for each term is included in every term
   description.

   Legacy Internet:  The portion of the Internet which does not run LISP
      and does not participate in LISP+ALT or any other mapping system.

   LISP site:  A LISP site is a set of routers in an edge network that
      are under a single technical administration.  LISP routers which that
      reside in the edge network are the demarcation points to separate
      the edge network from the core network.  See [I-D.ietf-lisp] for
      more details.

    Endpoint ID (EID):  An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  A packet that is
      emitted by a system contains EIDs in its headers and LISP headers
      are prepended only when the packet reaches an Ingress Tunnel
      Router (ITR) on the data path to the destination EID.  The source
      EID is obtained via existing mechanisms used to set a host's
      "local" IP address.  An EID is allocated to a host from an EID-
      prefix block associated with the site where the host is located.
      See [I-D.ietf-lisp] for more details.

   EID-prefix:  A a power-of-two block of EIDs which that are allocated to a
      site by an address allocation authority.  See [I-D.ietf-lisp] for
      more details.

   EID-Prefix Aggregate:  A set of EID-prefixes said to be aggregatable
      in the [RFC4632] sense.  That is, an EID-Prefix aggregate is
      defined to be a single contiguous power-of-two EID-prefix block.
      Such a block is characterized by a prefix and a length.  See
      [I-D.ietf-lisp] for more details.

   Routing LOCator (RLOC):  A RLOC is an IPv4 or IPv6 address of an
      egress tunnel router (ETR).  A RLOC is the output of a EID-to-RLOC an EID-to-
      RLOC mapping lookup.  An EID maps to one or more RLOCs.
      Typically, RLOCs are numbered from topologically-aggregatable topologically aggregatable
      blocks that are assigned to a site at each point to which it
      attaches to the global Internet; where the topology is defined by
      the connectivity of provider networks, RLOCs can be thought of as
      Provider Aggregatable (PA) addresses.  See [I-D.ietf-lisp] for
      more details.

    EID-to-RLOC Mapping:  A binding between an EID-Prefix and the RLOC-
      set that can be used to reach the EID-Prefix.  The general term
      "mapping" always refers to an EID-to-RLOC mapping.  See
      [I-D.ietf-lisp] for more details.

   Ingress Tunnel Router (ITR):  An Ingress Tunnel Router (ITR) is a
      router which that accepts receives IP packets from site end-systems on
      one side and sends LISP-encapsulated IP packets toward the
      Internet on the other side.  The router treats the "inner" IP
      destination address as an EID and performs an EID-to-RLOC mapping
      lookup.  The router then prepends an "outer" IP header with one of
      its globally-routable RLOCs in the source address field and the
      result of the mapping lookup in the destination address field.
      See [I-D.ietf-lisp] for more details.

   Egress Tunnel Router (ETR):  An Egress Tunnel Router (ETR) receives
      LISP-encapsulated IP packets from the Internet on one side and
      sends decapsulated IP packets to site end-systems on the other
      side.  An ETR router accepts an IP packet where the destination
      address in the "outer" IP header is one of its own RLOCs.  The
      router strips the "outer" header and forwards the packet based on
      the next IP header found.  See [I-D.ietf-lisp] for more details.

   Proxy ITR (PITR):  A Proxy-ITR (PITR) acts like an ITR but does so on
      behalf of non-LISP sites which send packets to destinations at
      LISP sites.  See [I-D.ietf-lisp-interworking] for more details.

   Proxy ETR (PETR):  A Proxy-ETR (PETR) acts like an ETR but does so on
      behalf of LISP sites which send packets to destinations at non-
      LISP sites.  See [I-D.ietf-lisp-interworking] for more details.

   Map Server (MS):  A network infrastructure component which that learns
      EID-to-RLOC EID-
      to-RLOC mapping entries from an authoritative source (typically an
      ETR).  A Map-Server publishes these mappings in the distributed
      mapping system.  See [I-D.ietf-lisp-ms] for more details.

   Map Resolver (MR):  A network infrastructure component which that accepts
      LISP Encapsulated Map-Requests, typically from an ITR, quickly
      determines whether or not the destination IP address is part of
      the EID namespace; if it is not, a Negative Map-Reply is
      immediately returned.  Otherwise, the Map-Resolver finds the
      appropriate EID-to-RLOC mapping by consulting the distributed
      mapping database system.  See [I-D.ietf-lisp-ms] for more details.

   The LISP Alternative Logical Topology (ALT):  The virtual overlay
      network made up of tunnels between LISP+ALT Routers.  The Border
      Gateway Protocol (BGP) runs between ALT Routers and is used to
      carry reachability information for EID-prefixes.  The ALT provides
      a way to forward Map-Requests toward the ETR that "owns" an EID-
      prefix.  See [I-D.ietf-lisp-alt] for more details.

   ALT Router:  The device on which runs the ALT.  The ALT is a static
      network built using tunnels between ALT Routers.  These routers
      are deployed in a roughly-hierarchical mesh in which routers at
      each level in the topology are responsible for aggregating EID-
      Prefixes learned from those logically "below" them and advertising
      summary prefixes to those logically "above" them.  Prefix learning
      and propagation between ALT Routers is done using BGP.  When an
      ALT Router receives an ALT Datagram, it looks up the destination
      EID in its forwarding table (composed of EID-Prefix routes it
      learned from neighboring ALT Routers) and forwards it to the
      logical next-hop on the overlay network.  The primary function of
      LISP+ALT routers is to provide a lightweight forwarding
      infrastructure for LISP control-plane messages (Map-Request and
      Map-Reply), and to transport data packets when the packet has the
      same destination address in both the inner (encapsulating)
      destination and outer destination addresses ((i.e., a Data Probe
      packet).  See [I-D.ietf-lisp-alt] for more details.

4.  Security Considerations

   This document does  Rationale and Intent

   With the current specifications, if an ITR is sending to all types of
   destinations (i.e., non-LISP destinations, LISP destinations not introduces new security threats in
   the IPv6 EID Block, and LISP
   architecture.

5.  Acknowledgments

   Marla Azinger, Chris Morrow, Peter Schoenmaker all made insightful
   comments on early versions of this draft.

6. destinations in the IPv6 EID Block) the
   only way to understand whether or not to encapsulate the traffic is
   to perform a cache lookup and, in case of cache-miss, send a Map-
   Request to the mapping system.  In the meanwhile, packets can be
   dropped.

   By defining an IPv6 EID Block is possible to configure the router so
   to natively forward all packets that have not a destination address
   in the block, without performing any lookup whatsoever.  This will
   give a tighter control over the traffic in the initial experimental
   phase, while facilitating its large-scale deployment.

   The EID Block will be used only at configuration level, it is
   RECOMMENDED not to hard-code in any way the IPv6 EID Block in the
   router hardware.  This allows to avoid locking out sites that may
   want to switch to LISP while keeping their own IPv6 prefix, which is
   not in the IPv6 EID Block.

5.  Expected use

   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   Block.  Such prefix will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use or registered to one or more Map-Server(s).
   Too guarantee reachability from the Legacy Internet the prefix could
   be announced in the BGP routing infrastructure by one or more
   PITR(s), possibly as part of a larger prefix, aggregating several
   prefixes of several sites.

6.  Action Plan

   This document requests IANA to initially allocate a /16 prefix out of
   the IPv6 addressing space for use as EID in LISP (Locator/ID
   Separation protocol).  It is suggested to IANA to temporarily avoid
   allocating any other address block the same /12 prefix the EID /16
   prefix belongs to.  This is to accommodate future requests of EID
   space without fragmenting the EID addressing space.  This will also
   help from an operational point of view, since it will be sufficient
   to change the subnet mask length in existing deployments.

   If in the future there will be need for a larger EID Block the
   address space adjacent the EID Block could be allocate by IANA
   according to the current policies.

7.  Routing Considerations

   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large aggregates of the IPv6 EID Block could
   be deployed.  By doing so, PITRs will attract traffic destined to
   LISP sites in order to encapsulate and forward it toward the specific
   destination LISP site.  Routers in the Legacy Internet MUST treat
   announcements of prefixes from the IPv6 EID Block as normal
   announcements, applying best current practice for traffic engineering
   and security.

   Even in a LISP site, not all routers need to run LISP elements.  In
   particular, routers that are not at the border of the local domain,
   used only for intra-domain routing, do not need to provide any
   specific LISP functionality but MUST be able to route traffic using
   addresses in the IPv6 EID Block.

   For the above-mentioned reasons, routers that do not run any LISP
   element, MUST NOT include any special handling code or hardware for
   addresses in the IPv6 EID Block.  In particular, it is RECOMMENDED
   that the default router configuration does not handle such addresses
   in any special way.  Doing differently could prevent communication
   between the Legacy Internet and LISP sites or even break local intra-
   domain connectivity.

8.  Security Considerations

   This document does not introduce new security threats in the LISP
   architecture nor in the Legacy Internet architecture.

9.  Acknowledgments

   Marla Azinger, Chris Morrow, Peter Schoenmaker all made insightful
   comments on early versions of this draft.

10.  IANA Considerations

   This document instructs the IANA to allocate assign a /16 IPv6 prefix for use
   as the global LISP EID space.

7. space using an hierarchical allocation as
   outlined in [RFC2434].  During the discussion related to this
   document, the LISP Working Group agreed in suggesting to IANA to
   reserve adjacent addressing space for future use as EID space if
   needs come.  Following the policies outlined in [RFC2434], such space
   will be assigned only upon IETF Consensus.  This document does not
   specify any specific value for the requested address block.

11.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-10
              draft-ietf-lisp-14 (work in progress), March June 2011.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 draft-ietf-lisp-alt-07
              (work in progress), March June 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01
              draft-ietf-lisp-interworking-02 (work in progress),
              August 2010.
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-06
              draft-ietf-lisp-ms-09 (work in progress), October 2010. June 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

Appendix A.  Document Change Log

   Version 00 Posted July 2011.

   o  Updated section "IANA Considerations"

   o  Added section "Rationale and Intent" explaining why the EID block
      allocation is useful.

   o  Added section "Expected Use" explaining how sites can request and
      use a prefix in the IPv6 EID Block.

   o  Added section "Action Plan" suggesting IANA to avoid allocating
      address space adjacent the allocated EID block in order to
      accommodate future EID space requests.

   o  Added section "Routing Consideration" describing how routers not
      running LISP deal with the requested address block.

   o  Added the present section to keep track of changes.

   o  Rename of draft-meyer-lisp-eid-block-02.txt.

Authors' Addresses

   Luigi Iannone
   Deutsche Telekom Laboratories

   Email: luigi@net.t-labs.tu-berlin.de

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Cisco Systems, Inc.

   Email: dmm@cisco.com

   Vince Fuller
   Cisco Systems, Inc.

   Email: vaf@cisco.com
--Apple-Mail-24-597977572 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail-24-597977572-- --Apple-Mail-23-597977572-- From internet-drafts@ietf.org Sat Jul 2 09:23:36 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116711E815B; Sat, 2 Jul 2011 09:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbw0udfdl5CX; Sat, 2 Jul 2011 09:23:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E0E11E8155; Sat, 2 Jul 2011 09:23:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110702162336.28674.16246.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2011 09:23:36 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:23:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP EID Block Author(s) : Luigi Iannone Darrel Lewis David Meyer Vince Fuller Filename : draft-ietf-lisp-eid-block-00.txt Pages : 9 Date : 2011-07-02 This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used by sites deploying LISP as EID (Endpoint IDentifier) addressing space for local intra-domain routing and global endpoint identification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-00.txt From dino@cisco.com Sat Jul 2 10:49:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8CC11E80AD for ; Sat, 2 Jul 2011 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEkS2asadqhZ for ; Sat, 2 Jul 2011 10:49:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id AA7BA11E8075 for ; Sat, 2 Jul 2011 10:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2049; q=dns/txt; s=iport; t=1309628953; x=1310838553; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=tl8OXQFhz/4xHbyWa2V38MCVLVxhgKDtN7ofeLHF0dU=; b=jMFPZ9/PlsysdM7sADebP557hZj+LhvWVzkxVuHRUanGAci9ReSRKWuI x2aDI1xOW0NMU0gcduF25RS4wXk4pS/CE9HHP+hgw2jfXR+N+qpqInQSF dN+czFzFNjgj1LcVujHDY4Re3D9FMk53+YaVokLH2gemIl/FCvmzCjWsY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALNZD06rRDoI/2dsb2JhbABSqAF3iHqjV50qhjYEhz+Kd4R4i14 X-IronPort-AV: E=Sophos;i="4.65,464,1304294400"; d="scan'208";a="725875344" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2011 17:49:13 +0000 Received: from [192.168.1.4] (sjc-vpn6-1263.cisco.com [10.21.124.239]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p62HnDRu021027; Sat, 2 Jul 2011 17:49:13 GMT Message-Id: <3CAF75CC-C52B-44A1-9934-07ED2F28CC18@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <11DCF83E-E978-4703-A677-AF74CD776624@net.t-labs.tu-berlin.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 2 Jul 2011 10:49:13 -0700 References: <20110702143324.1031.95238.idtracker@ietfa.amsl.com> <11DCF83E-E978-4703-A677-AF74CD776624@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.936) Cc: David Meyer , lisp@ietf.org Subject: Re: [lisp] Fwd: I-D Action: draft-lisp-eid-block-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 17:49:14 -0000 Shouldn't the file name be "draft-ietf-lisp-eid-block-00" and not "draft-lisp-eid-block-00"? Just wondering, Dino On Jul 2, 2011, at 7:40 AM, Luigi Iannone wrote: > Hi All, > > the new draft for the EID block request has been submitted. > > Attached the WDiff w.r.t the previous version. > > Luigi > > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Date: July 2, 2011 16:33:24 GMT+02:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-lisp-eid-block-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : LISP EID Block >> Author(s) : Luigi Iannone >> Darrel Lewis >> David Meyer >> Vince Fuller >> Filename : draft-lisp-eid-block-00.txt >> Pages : 9 >> Date : 2011-07-02 >> >> This is a direction to IANA to allocate a /16 IPv6 prefix for use >> with the Locator/ID Separation Protocol (LISP). The prefix will be >> used by sites deploying LISP as EID (Endpoint IDentifier) >> addressing >> space for local intra-domain routing and global endpoint >> identification. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-lisp-eid-block-00.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > 00.html> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sat Jul 2 10:49:43 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513DF11E8142; Sat, 2 Jul 2011 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cgtkmX6+y7A; Sat, 2 Jul 2011 10:49:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id E203811E8075; Sat, 2 Jul 2011 10:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1357; q=dns/txt; s=iport; t=1309628982; x=1310838582; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=+1ozRvRw6Q5Xp3jxR3imeW6hJiaIaVIezKocWw9I20k=; b=UIGhhj7XfO9sg1B1mKPAT5+fo4H2kgxmq3fkQ2fzi41c2X5BykJRl0KF Wk0AqsDN63wdVXt41+iWQy4gOfA9VgUJBP1QlBI7P3qbGHPkAe01LXC3+ S9o2zkGDXq6RW7aGGg65/umD3z5XVb+ua0RV57VGqX9Y1Wt6Rqn0P9TPO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQJALNZD06rRDoI/2dsb2JhbABSmQ+OcneIeqNXnSqGNgSHP4p3hHiLXg X-IronPort-AV: E=Sophos;i="4.65,464,1304294400"; d="scan'208";a="725875398" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2011 17:49:42 +0000 Received: from [192.168.1.4] (sjc-vpn6-1263.cisco.com [10.21.124.239]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p62HnDRv021027; Sat, 2 Jul 2011 17:49:42 GMT Message-Id: <299E801D-2A4D-4465-BB7E-7F4A2BAA0EB7@cisco.com> From: Dino Farinacci To: internet-drafts@ietf.org In-Reply-To: <20110702162336.28674.16246.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 2 Jul 2011 10:49:42 -0700 References: <20110702162336.28674.16246.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org, i-d-announce@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-eid-block-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 17:49:43 -0000 Nevermind. ;-) Dino On Jul 2, 2011, at 9:23 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Locator/ID Separation > Protocol Working Group of the IETF. > > Title : LISP EID Block > Author(s) : Luigi Iannone > Darrel Lewis > David Meyer > Vince Fuller > Filename : draft-ietf-lisp-eid-block-00.txt > Pages : 9 > Date : 2011-07-02 > > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used by sites deploying LISP as EID (Endpoint IDentifier) addressing > space for local intra-domain routing and global endpoint > identification. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-eid-block-00.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Mon Jul 4 10:40:12 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B901C1F0C88; Mon, 4 Jul 2011 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.1 X-Spam-Level: X-Spam-Status: No, score=-82.1 tagged_above=-999 required=5 tests=[BAYES_99=3.5, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tytIfLH6uxKt; Mon, 4 Jul 2011 10:40:11 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id DF5471F0C68; Mon, 4 Jul 2011 10:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C367F324764D; Mon, 4 Jul 2011 10:39:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.1.18] (pool-96-245-82-167.phlapa.fios.verizon.net [96.245.82.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 67C823228BEB; Mon, 4 Jul 2011 10:39:41 -0700 (PDT) Message-ID: <4E11FADC.8090702@joelhalpern.com> Date: Mon, 04 Jul 2011 13:39:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "lisp@ietf.org" , "karp@ietf.org" Content-Type: multipart/mixed; boundary="------------070006080302070807030003" Subject: [lisp] Fwd: Nomcom 2011-2012: Third Call for Volunteers X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:40:12 -0000 This is a multi-part message in MIME format. --------------070006080302070807030003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit -------- Original Message -------- Subject: Nomcom 2011-2012: Third Call for Volunteers Date: Mon, 4 Jul 2011 08:47:17 -0700 (PDT) From: NomCom Chair To: IETF Announcement list CC: ietf@ietf.org This is the Third call for Volunteers for the 2011-12 Nomcom. We are almost through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 84 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 09:00 EDT on June 29 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 84 volunteers who have thus far been qualified by the secretariat are: Alia Atlas,Juniper Networks Lixia Zhang,UCLA Wassim Haddad ,Ericsson Glen Zorn,Network Zen Richard Barnes,BBN Technologies Stephen Kent,BBN Technologies Scott Mansfield,Ericsson Tina TSOU (Ting ZOU),FutureWei Technologies Fernando Gont,UTN/FRH Karen Seo,BBN Technologies Jie Dong,Huawei Technologies Mach Chen,Huawei Technologies Co. Ltd. Sheng Jiang,Huawei Technologies Co. Ltd. Dimitri Papadimitriou,Alcatel-Lucent Thomas D. Nadeau,CA Technologies David Meyer,Cisco Systems/University of Oregon Wesley George,Time Warner Cable Cullen Jennings,Cisco Stephen Hanna,Juniper Networks Stephan Wenger,Bidyo Inc. Keyur Patel,Cisco Systems Michael (Mike) Hamilton,BreakingPoint Systems Behcet Sarikaya,Huawei USA Mark Townsley,Cisco Systems Fred Baker,Cisco Systems Brian Trammell,ETH Zürich Sam Hartman,Painless Security Chris Griffiths,Comcast George Michaelson,APNIC Jiankang Yao,CNNIC Sohel Khan,Comcast Dacheng Zhang,Huawei Lianshu Zheng,Huawei Technologies Hui Deng,China Mobile Gang Chen,China Mobile Mirja Kühlewind,University of Stuttgart IKR John E Drake,Juniper Networks Matt Lepinski,BBN Technologies Subir Das,Telcordia Technologies Inc Yi Zhao,Huawei John Scudder,Juniper Networks Christer Holmberg,LM Ericsson Teemu Savolainen,Nokia Samita Chakrabarti,Ericsson Jaap Akkerhuis,NLnet labs Jason Weil,Time Warner Cable Randy Bush,Internet Initiative Japan Christian Schmidt,Nokia Siemens Networks Sean Shen,CNNIC Lou Berger,LabN Consulting L.L.C. Donald Eastlake,Huawei Xiaohu Xu,Huawei Technologies co. Ltd. Börje Ohlman,Ericsson Deborah Brungard,AT&T Magnus Westerlund,Ericsson Zhen Cao,China Mobile Hadriel Kaplan,Acme Packet Lilla Dovner,Ericsson John Jason Brzozowski,Comcast Jonne Soininen,Renesas Mobile Javier Ubillos,Swedish Institute of Computer Science Eric Gray,Ericsson Thomas Herbst,Silver Spring Networks Ning Zong,Huawei Technologies Haibin Song,Huawei Technologies Yingjie Gu,Huawei Technologies Hongyu Li,Huawei Technologies Terry Manderson,ICANN Ari Keranen,Ericsson Jouni Korhonen,Nokia Siemens Networks Bhumip Khasnabish,ZTE USA Inc. Dapeng Liu,China Mobile Fangwei Hu,ZTE Corporation Ole Troan,Cisco Pascal Thubert,Cisco Wojciech Dec,Cisco Gunter Van de Velde,Cisco Ning So,Verizon Inc./University of Texas at Dallas Guoman liu,ZTE Simon Pietro Romano,Meetecho/University of Napoli Luca Martini,Cisco Bill VerSteeg,Cisco Toerless Eckert,Cisco Systems Joseph Salowey,Cisco Systems The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process very soon. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com --------------070006080302070807030003 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg0K --------------070006080302070807030003-- From internet-drafts@ietf.org Mon Jul 4 10:46:18 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C421F8612; Mon, 4 Jul 2011 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QzjiyCABGQQ; Mon, 4 Jul 2011 10:46:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9A21F85E4; Mon, 4 Jul 2011 10:46:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704174618.4641.55973.idtracker@ietfa.amsl.com> Date: Mon, 04 Jul 2011 10:46:18 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-00.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:46:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Threats Analysis Author(s) : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-00.txt Pages : 29 Date : 2011-07-04 This document analyzes the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-threats-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-threats-00.txt From terry.manderson@icann.org Mon Jul 4 17:44:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9CC1F0C95 for ; Mon, 4 Jul 2011 17:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0EHxviva4MW for ; Mon, 4 Jul 2011 17:44:26 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFD1F0C7C for ; Mon, 4 Jul 2011 17:44:26 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 4 Jul 2011 17:44:26 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 4 Jul 2011 17:44:23 -0700 Thread-Topic: Close of WGLC Thread-Index: Acw6rK7mKPjZW/4KWk6DMC/BxX4Vpw== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] Close of WGLC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 00:44:27 -0000 Hi All, Joel and I have held open the LC for the set of LISP documents for an extended period of time to ensure all comments were addressed. This closes the WGLC (finally) for: draft-ietf-lisp draft-ietf-lisp-alt draft-ietf-lisp-interworking draft-ietf-lisp-lig draft-ietf-lisp-map-versioning draft-ietf-lisp-ms draft-ietf-lisp-multicast We will try to get the write-ups for these done as soon as possible. Thanks to reviewers and authors for their efforts. Cheers Terry From terry.manderson@icann.org Mon Jul 4 17:56:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA17621F874B for ; Mon, 4 Jul 2011 17:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.466 X-Spam-Level: X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd-q+R5Z-sxn for ; Mon, 4 Jul 2011 17:56:14 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7270B21F873E for ; Mon, 4 Jul 2011 17:56:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 4 Jul 2011 17:56:14 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 4 Jul 2011 17:56:11 -0700 Thread-Topic: thoughts on re-chartering the WG Thread-Index: Acw6rlTm6foeaaWWgEyhkDkMbWLDAA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] thoughts on re-chartering the WG X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 00:56:15 -0000 All, With the WGLC now closed for a set of items I would like to draw your attention to the charter and milestones set for LISP: Goals and Milestones: Mar 2010 - Submit base LISP specification to the IESG as Experimental Mar 2010 - Submit base ALT specification to the IESG as Experimental Mar 2010 - Submit the LISP Interworking specification to the IESG as Experimental Jun 2010 - Submit the LISP Map Server specification to the IESG as Experimental Jun 2010 - Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 - Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 - Submit a preliminary analysis as Informational Dec 2010 - Re-charter or close. This suggests (apart from us being a year late on milestones) that two item= s remain: Dec 2010 - Submit a preliminary analysis as Informational Dec 2010 - Re-charter or close. Given we have a number of adopted WG items coming along: draft-ietf-lisp-deployment draft-ietf-lisp-eid-block draft-ietf-lisp-mib draft-ietf-lisp-threats draft-ietf-lisp-sec I think a discussion on a LISP re-charter is in order. I suspect we will have time in Quebec to expand on the discussion. Cheers Terry From internet-drafts@ietf.org Tue Jul 5 07:15:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670B21F85C5; Tue, 5 Jul 2011 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP5+DlnDlHlD; Tue, 5 Jul 2011 07:15:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4221F8500; Tue, 5 Jul 2011 07:15:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705141542.19318.19557.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 07:15:42 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:15:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map-Versioning Author(s) : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-map-versioning-02.txt Pages : 20 Date : 2011-07-05 This document describes the LISP Map-Versioning mechanism, which provides in-packet information about EID-to-RLOC mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating xTRs about modifications of the mappings used to encapsulate packets. The mechanism is transparent to legacy implementations, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by xTRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-02.txt From luigi@net.t-labs.tu-berlin.de Tue Jul 5 07:20:11 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EF711E80B2 for ; Tue, 5 Jul 2011 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87gtgzZYcMWr for ; Tue, 5 Jul 2011 07:20:08 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 22BDF11E80E4 for ; Tue, 5 Jul 2011 07:20:06 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id C77087000137; Tue, 5 Jul 2011 16:20:01 +0200 (CEST) From: Luigi Iannone Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-855919705 Date: Tue, 5 Jul 2011 16:20:01 +0200 References: <20110705141542.19318.19557.idtracker@ietfa.amsl.com> To: lisp@ietf.org Message-Id: X-Mailer: Apple Mail (2.1084) Subject: [lisp] Fwd: I-D Action: draft-ietf-lisp-map-versioning-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:20:11 -0000 --Apple-Mail-4-855919705 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, we submitted un updated version of the map-versioning draft (thanks to = Alia and Jesper for their review and suggestions). Attached the RFCDiff highlighting the changes. Luigi Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 5, 2011 16:15:42 GMT+02:00 > To: i-d-announce@ietf.org > Cc: lisp@ietf.org > Subject: I-D Action: draft-ietf-lisp-map-versioning-02.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF. >=20 > Title : LISP Map-Versioning > Author(s) : Luigi Iannone > Damien Saucez > Olivier Bonaventure > Filename : draft-ietf-lisp-map-versioning-02.txt > Pages : 20 > Date : 2011-07-05 >=20 > This document describes the LISP Map-Versioning mechanism, which > provides in-packet information about EID-to-RLOC mappings used to > encapsulate LISP data packets. The proposed approach is based on > associating a version number to EID-to-RLOC mappings and transport > such a version number in the LISP specific header of LISP- > encapsulated packets. LISP Map-Versioning is particularly useful to > inform communicating xTRs about modifications of the mappings used = to > encapsulate packets. The mechanism is transparent to legacy > implementations, since in the LISP-specific header and in the Map > Records, bits used for Map-Versioning can be safely ignored by xTRs > that do not support the mechanism. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-4-855919705 Content-Type: multipart/mixed; boundary=Apple-Mail-5-855919706 --Apple-Mail-5-855919706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = All,

we submitted un updated version of the = map-versioning draft (thanks to Alia and Jesper for their review and = suggestions).

Attached the RFCDiff highlighting = the = changes.

Luigi


=
Begin forwarded message:

Date: July 5, 2011 16:15:42 GMT+02:00
Subject: I-D Action: = draft-ietf-lisp-map-versioning-02.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the Locator/ID = Separation Protocol Working Group of the IETF.

Title =           : LISP = Map-Versioning
Author(s) =       : Luigi Iannone
=             &n= bsp;           &nbs= p;Damien Saucez
=             &n= bsp;           &nbs= p;Olivier Bonaventure
Filename =        : = draft-ietf-lisp-map-versioning-02.txt
Pages =           : = 20
= Date =            : = 2011-07-05

  This document describes the LISP = Map-Versioning mechanism, which
  provides in-packet = information about EID-to-RLOC mappings used to
=   encapsulate LISP data packets.  The proposed approach = is based on
  associating a version number to EID-to-RLOC = mappings and transport
  such a version number in the LISP = specific header of LISP-
  encapsulated packets. =  LISP Map-Versioning is particularly useful to
=   inform communicating xTRs about modifications of the = mappings used to
  encapsulate packets.  The = mechanism is transparent to legacy
  implementations, = since in the LISP-specific header and in the Map
=   Records, bits used for Map-Versioning can be safely ignored = by xTRs
  that do not support the mechanism.


A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versionin= g-02.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-0= 2.txt
_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt
= --Apple-Mail-5-855919706 Content-Disposition: attachment; filename="RFCDiff-01->02.html" Content-Type: text/html; name="RFCDiff-01->02.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-map-versioning-01.txt draft-ietf-lisp-map-versioning-02.txt 

Network Working Group                                         L. Iannone
Internet-Draft                              TU Berlin - Deutsche Telekom
Intended status: Experimental                            Laboratories AG
Expires: September 12, 2011 January 6, 2012                                       D. Saucez
                                                          O. Bonaventure
                                        Universite catholique de Louvain
                                                          March 11,
                                                            July 5, 2011

                          LISP Map-Versioning
                 draft-ietf-lisp-map-versioning-01.txt
                 draft-ietf-lisp-map-versioning-02.txt

Abstract

   This document describes the LISP Map-Versioning mechanism, which
   provides in-packet information about EID-to-RLOC mappings used to
   encapsulate LISP data packets.  The proposed approach is based on
   associating a version number to EID-to-RLOC mappings and transport
   such a version number in the LISP specific header of LISP-
   encapsulated packets.  LISP Map-Versioning is particularly useful to
   inform communicating xTRs about modifications of the mappings used to
   encapsulate packets.  The mechanism is transparent to legacy
   implementations, since in the LISP-specific header and in the Map
   Records, bits used for Map-Versioning can be safely ignored by xTRs
   that do not support the mechanism.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 12, 2011. January 6, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Definitions of Terms . . . . . . . . . . . . . . . . . . . . .  5  4
   4.  EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . .  5  4
     4.1.  The Null Map-Version . . . . . . . . . . . . . . . . . . .  6  5
   5.  Dealing with Map-Version numbers . . . . . . . . . . . . . . .  7  6
     5.1.  Handling Destination Map-Version number  . . . . . . . . .  7
     5.2.  Handling Source Map-Version number . . . . . . . . . . . .  9  8
   6.  LISP header and Map-Version numbers  . . . . . . . . . . . . . 10  9
   7.  Map Record and Map-Version . . . . . . . . . . . . . . . . . . 11 10
   8.  Benefits and case studies for Map-Versioning . . . . . . . . . 12 11
     8.1.  Synchronization of different xTRs  . . . . . . . . . . . . 12 11
     8.2.  Map-Versioning and unidirectional traffic  . . . . . . . . 13 12
     8.3.  Map-Versioning and interworking  . . . . . . . . . . . . . 13 12
       8.3.1.  Map-Versioning and Proxy-ITRs  . . . . . . . . . . . . 14 13
       8.3.2.  Map-Versioning and LISP-NAT  . . . . . . . . . . . . . 14 13
       8.3.3.  Map-Versioning and Proxy-ETRs  . . . . . . . . . . . . 14 13
     8.4.  RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15 14
     8.5.  Map-Version for lightweight LISP implementation  . . . . . 15 14
   9.  Incremental deployment and implementation status . . . . . . . 16 15
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16 15
     10.1. Map-Versioning against traffic disruption  . . . . . . . . 17 16
     10.2. Map-Versioning against reachability information DoS  . . . 17 16
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17
     13.2. Informative References . . . . . . . . . . . . . . . . . . 18 17
   Appendix A.  Estimation of time before Map-Version wrap-around . . 19 18
   Appendix B.  Document Change Log . . . . . . . . . . . . . . . . . 20 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 20

1.  Introduction

   This document describes the Map-Versioning mechanism used to provide
   information on changes in the EID-to-RLOC mappings used in the LISP
   ([I-D.ietf-lisp]) context to perform packet encapsulation.  The
   mechanism is totally transparent to xTRs not supporting such
   functionality.  It is not meant to replace any existing LISP
   mechanism, but rather to complete them providing new functionalities.
   The basic mechanism is to associate a Map-Version number to each LISP
   EID-to-RLOC mapping and transport such a version number in the LISP-
   specific header.  When a mapping changes, a new version number is
   assigned to the updated mapping.  A change in an EID-to-RLOC mapping
   can be a change in the RLOCs set, by adding or removing one or more
   RLOCs, but it can also be a change in the priority or weight of one
   or more RLOCs.

   When Map-Versioning is used, LISP-encapsulated data packets contain
   the version number of the two mappings used to select the RLOCs in
   the outer header (i.e., both source and destination).  These version
   numbers are encoded in the 24 low-order bits of the first longword of
   the LISP header and indicated by a specific bit in the flags (first 8
   high-order bits of the first longword of the LISP header).  Note that
   not all packets need to carry version numbers.

   When an ITR encapsulates a data packet, with a LISP header containing
   the Map-Version numbers, it puts in the LISP-specific header two
   version numbers:

   1.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Database) used to select the source RLOC.

   2.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Cache) used to select the destination RLOC.

   This operation is two-fold.  On the one hand, it enables the ETR
   receiving the packet to know if the ITR has the latest version number
   that any ETR at the destination EID site has provided to the ITR in a
   Map-Reply.  If it is not the case the ETR can send to the ITR a Map-
   Request containing the updated mapping or soliciting a Map-Request
   from the ITR (both cases are already defined in [I-D.ietf-lisp]).  In
   this way the ITR can update its cache.  On the other hand, it enables
   an ETR receiving such a packet to know if it has in its EID-to-RLOC
   Cache the latest mapping for the source EID (in case of bidirectional
   traffic).  If it is not the case a Map-Request can be send.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Definitions of Terms

   The present document uses terms already defined in main LISP
   specification [I-D.ietf-lisp].  Hereafter are defined only the terms
   that are specific to the Map-Versioning mechanism.

   Map-Version number:  An unsigned 12-bits assigned to an EID-to-RLOC
      mapping, not including the value 0 (0x000).

   Null Map-Version:  The 12-bits null value of 0 (0x000) is not used as
      Map-Version number.  It is used to signal that no Map-Version
      number is assigned to the EID-to-RLOC mapping.

   Source Map-Version number:  Map-Version number of the EID-to-RLOC
      mapping used to select the source address (RLOC) of the outer IP
      header of LISP-encapsulated packets.

   Destination Map-Version number:  Map-Version number of the EID-to-
      RLOC mapping used to select the destination address (RLOC) of the
      outer IP header of LISP-encapsulated packets.

4.  EID-to-RLOC Map-Version number

   The EID-to-RLOC Map-Version number consists in an unsigned 12-bits
   integer.  The version number is assigned in a per-mapping fashion,
   meaning that different mappings will have assigned a different
   version number, which is also updated independently.  An update in
   the version number (i.e., a newer version) consist in incrementing by
   one the older version number.  Appendix A contains a rough estimation
   of the wrap-around time for the Map-Version number.

   The space of version numbers has a circular order where half of the
   version numbers is greater than the current Map-Version number and
   the other half is smaller than current Map-Version number.  In a more
   formal way, assuming we have two version numbers V1 and V2 and that
   the numbers are expressed on N bits, the following three cases may
   happen:

   V1 = V2 :  This is the exact match case.

   V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).

   V1 > V2 :  True if and only if V1 > V2 > (V1 - 2**(N-1)).

   Using 12 bits, as defined in this document, and assuming a Map-
   Version value of 69, Map-Version numbers in the range [70; 69 + 2047]
   are greater than 69, while Map-Version numbers in the range [69 +
   2048; (69 + 4095) mod 4096] are smaller than 69.

   The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
   randomly generated.  However, it MUST NOT be set to the Null Map-
   Version value (0x000), because it has a special meaning (see
   Section 4.1).

4.1.  The Null Map-Version

   The value 0x000 (zero) is not a valid Map-Version number indicating
   the version of the EID-to-RLOC mapping.  Such a value is used for
   special purposes and is named the Null Map-Version number.

   The Null Map-Version MAY appear in the LISP specific header as either
   Source Map-Version number (cf. Section 5.2) or Destination Map-
   Version number (cf. Section 5.1).  When the Source Map-Version number
   is set to the Null Map-version value it means that no map version
   information is conveyed for the source site.  This means that if a
   mapping exists for the source EID in the EID-to-RLOC Cache, then the
   ETR MUST NOT compare the received Null Map-Version with the content
   of the EID-to-RLOC cache.  When the Destination Map-version number is
   set to the Null Map-version value it means that no map version
   information is conveyed for the destination site.  This means that
   the ETR MUST NOT compare the value with the Map-Version number of the
   mapping for the destination EID present in the EID-to-RLOC Database.

   The other use of the Null Map-Version number is in the Map Records,
   which are part of the Map-Request, Map-Reply and Map-Register
   messages (defined in [I-D.ietf-lisp]).  Map Records that have a Null
   Map-Version number indicate that there is no Map-Version number
   associated with the mapping.  This means that LISP encapsulated
   packets, destined to the EID-Prefix the Map Record refers to, MUST
   NOT
   either not contain any Map-Version numbers (i.e., V (V bit MUST always be 0).  In
   other words, the Null Map-Version number signals set to the ITR using the
   mapping that the Map-Versioning is not supported, 0), or even if
   supported it
   contains Map-Version numbers (V bit set to 1) then the destination
   Map-Version number MUST NOT be used for that specific EID-Prefix. set to the Null Map-Version number.  Any
   value different from zero means that Map-Versioning is supported and
   MAY be used.

   The fact that the 0 value has a special meaning for the Map-Version
   number implies that, when updating a Map-Version number because of a
   change in the mapping, if the next value is 0 then Map-Version number
   MUST be incremented by 2 (i.e., set to 1, which is the next valid
   value).

5.  Dealing with Map-Version numbers

   The main idea of using Map-Version numbers is that whenever there is
   a change in the mapping (e.g., adding/removing RLOCs, a change in the
   weights due to TE policies, or a change in the priorities) or an ISP
   realizes that one or more of its own RLOCs are not reachable anymore
   from a local perspective (e.g., through IGP, or policy changes) the
   ISP updates the mapping also assigning a new Map-Version number.

   To each mapping, a version number is associated and changes each time
   the mapping is changed.  Note that map-versioning does not introduce
   any new problem concerning the coordination of different ETRs of a
   domain.  Indeed, ETRs belonging to the same LISP site must return for
   a specific EID-prefix the same mapping.  In principle this is
   orthogonal to whether or not map-versioning is used.  The ETR's
   synchronization problem is out of the scope of this document.

   In order to announce in a data-driven fashion that the mapping has
   been updated, Map-Version numbers used to create the outer IP header
   of the LISP-encapsulated packet are embedded in the LISP-specific
   header.  This means that the header needs to contain two Map-Version
   numbers:

   o  The Source Map-Version number of the EID-to-RLOC mapping in the
      EID-to-RLOC Database used to select the source RLOC.

   o  The Destination Map-Version number of the EID-to-RLOC mapping in
      the EID-to-RLOC Cache used to select the destination RLOC.

   By embedding both Source Map-Version number and Destination Map-
   Version number an ETR receiving a LISP packet with Map-Version
   numbers, can perform the following checks:

   1.  The ITR that has sent the packet has an up-to-date mapping in its
       cache for the destination EID and is performing encapsulation
       correctly.

   2.  In case of bidirectional traffic, the mapping in the local ETR
       EID-to-RLOC cache for the source EID is up-to-date.

   If one or both of the above conditions do not hold, the ETR can send
   a Map-Request either to make the ITR aware that a new mapping is
   available (see Section 5.1) or to update the mapping in the local
   cache (see Section 5.2).

5.1.  Handling Destination Map-Version number

   When an ETR receives a packet, the Destination Map-Version number
   relates to the mapping for the destination EID for which the ETR is a
   RLOC.  This mapping is part of the ETR EID-to-RLOC Database.  Since
   the ETR is authoritative for the mapping, it has the correct and up-
   to-date Destination Map-Version number.  A check on this version
   number can be done, where the following cases can arise:

   1.  The packets arrive with the same Destination Map-Version number
       stored in the EID-to-RLOC Database.  This is the regular case.
       The ITR sending the packet has in its EID-to-RLOC Cache an up-to-
       date mapping.  No further actions are needed.

   2.  The packet arrives with a Destination Map-Version number greater
       (i.e., newer) than the one stored in the EID-to-RLOC Database.
       Since the ETR is authoritative on the mapping, this means that
       someone is not behaving correctly w.r.t. the specifications, thus
       the packet carries a not valid version number and SHOULD be
       silently dropped.

   3.  The packets arrive with a Destination Map-Version number smaller
       (i.e., older) than the one stored in the EID-to-RLOC Database.
       This means that the ITR sending the packet has an old mapping in
       its EID-to-RLOC Cache containing stale information.  The ITR
       sending the packet has to be informed that a newer mapping is
       available.  This is done with a Map-Request message sent back to
       the ITR.  The Map-Request will either trigger a Map-Request back
       using the SMR bit or it will piggyback the newer mapping.  These
       are not new mechanisms; how to SMR or piggyback mappings in Map-
       Request messages is already described in [I-D.ietf-lisp], while
       their security is discussed in [I-D.saucez-lisp-security]. [I-D.ietf-lisp-threats].  These
       Map-Request messages should be rate limited (rate limitation
       policies are also described in [I-D.ietf-lisp]).  The feature
       introduced by Map-Version numbers is the possibility of blocking
       traffic from ITRs not using the latest mapping.  Indeed, after a
       certain number of retries, if the Destination Map-Version number
       in the packets is not updated, the ETR MAY silently drop packets
       with a stale Map-Version number.  This because either the ITR is
       refusing to use the mapping for which the ETR is authoritative or
       (worse) it might be some form of attack.

   The rule in the third case MAY be more restrictive.  If the mapping
   has been the same for a period of time as long as the TTL (defined in
   [I-D.ietf-lisp]) of the previous version of the mapping, all packets
   arriving with an old Map-Version SHOULD be silently dropped right
   away without issuing any Map-Request.  The reason that allows such
   action is the fact that if the new mapping with the updated version
   number has been unchanged for at least the same time as the TTL of
   the older mapping, all the entries in the caches of ITRs must have
   expired.  Hence, all ITRs sending traffic should have refreshed the
   mapping according to [I-D.ietf-lisp].  If packets with old Map-
   Version number are still received, then either someone has not
   respected the TTL, or it is a form of spoof/attack.  In both cases
   this is not valid behavior w.r.t. the specifications and the packet
   SHOULD be silently dropped.

   LISP-encapsulated packets with the V-bit set, when the original
   mapping in the EID-to-RLOC Database has version number set to the
   Null Map-Version value, MAY be silently dropped.  As explained in
   Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
   means that ITRs, using the mapping for encapsulation, MUST NOT use
   Map-Version number in the LISP-specific header.

   For LISP-encapsulated packets with the V-bit set, when the original
   mapping in the EID-to-RLOC Database has version number set to a value
   different from the Null Map-Version value, a Destination Map-Version
   number equal to the Null Map-Version value means that the Destination
   Map-Version number MUST be ignored.

5.2.  Handling Source Map-Version number

   When an ETR receives a packet, the Source Map-Version number relates
   to the mapping for the source EID for which the ITR that sent the
   packet is authoritative.  If the ETR has an entry in its EID-to-RLOC
   Cache for the source EID, then a check can be performed and the
   following cases can arise:

   1.  The packet arrives with the same Source Map-Version number stored
       in the EID-to-RLOC Cache.  This is the correct regular case.  The
       ITR has in its cache an up-to-date copy of the mapping.  No
       further actions are needed.

   2.  The packet arrives with a Source Map-Version number greater
       (i.e., newer) than the one stored in the local EID-to-RLOC Cache.
       This means that ETR has in its cache a mapping that is stale and
       needs to be updated.  A Map-Request SHOULD be sent to get the new
       mapping for the source EID.  This is a normal Map-Request message
       sent through the mapping system and MUST respect the
       specifications in [I-D.ietf-lisp], including rate limitation
       policies.

   3.  The packet arrives with a Source Map-Version number smaller
       (i.e., older) than the one stored in the local EID-to-RLOC Cache.
       Such a case is not valid w.r.t. the specifications.  Indeed, if
       the mapping is already present in the EID-to-RLOC Cache, this
       means that an explicit Map-Request has been sent and a Map-Reply
       has been received from an authoritative source.  Assuming that
       the mapping system is not corrupted anyhow, the Map-Version in
       the EID-to-RLOC Cache is the correct one and the packet MAY be
       silently dropped.

   If the ETR does not have an entry in the EID-to-RLOC Cache for the
   source EID (e.g., in case of unidirectional traffic) then the Source
   Map-Version number can be safely ignored.

   For LISP-encapsulated packets with the V-bit set, if the Source Map-
   Version number is the Null Map-Version value, it means that the
   Source Map-Version number MUST be ignored.

6.  LISP header and Map-Version numbers

   In order for the versioning approach to work, the LISP specific
   header has to carry both Source Map-Version number and Destination
   Map-Version number.  This is done by setting the V-bit in the LISP
   specific header.  When the V-bit is set the low-order 24-bits of the
   first longword (which usually contains the nonce) are used to
   transport both source and destination Map-Version numbers.  In
   particular the first 12 bits are used for Source Map-Version number
   and the second 12 bits for the Destination Map-Version number.

   Hereafter is the example of LISP header carrying version numbers in
   the case of IPv4-in-IPv4 encapsulation.  The same setting can be used
   for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |N|L|E|V|I|flags|  Source Map-Version   |Destination Map-Version|
   LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Instance ID/Locator Status Bits               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source Map-Version number (12 bits):  Map-Version of the mapping used
      by the ITR to select the RLOC present in the "Source Routing
      Locator" field.  How to set on transmission and handle on
      reception this value is described in Section 5.2.

   Destination Map-Version number (12 bits):  Map-Version of the mapping
      used by the ITR to select the RLOC present in the "Destination
      Routing Locator" field.  How to set on transmission and handle on
      reception this value is described in Section 5.1.

   The present document just specifies how to use the low-order 24-bits
   of the first longword of the LISP-specific header when the V-bit is
   set to 1.  All other cases, including the bit fields of the rest of
   the LISP-specific header and the whole LISP packet format are
   specified in [I-D.ietf-lisp].  Not all of the LISP encapsulated
   packets need to carry version numbers.  When Map-Version numbers are
   carried the V-bit MUST be set to 1.  All legal combinations of the
   flags, when the V-bit is set to 1, are described in [I-D.ietf-lisp].

7.  Map Record and Map-Version

   To accommodate the proposed mechanism, the Map Records that are
   transported on Map-Request/Map-Reply/Map-Register messages need to
   carry the Map-Version number as well.  For this purpose the 12-bits
   before the EID-AFI field in the Record that describe a mapping is
   used.  This is defined in [I-D.ietf-lisp] and reported here as
   example.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Map-Version Number:  Map-Version of the mapping contained in the
      Record.  As explained in Section 4.1 this field can be zero (0),
      meaning that no Map-Version is associated to the mapping, hence
      packets that are LISP-encapsulated using this mapping MUST NOT
      contain Map-Version numbers in the LISP specific header and the
      V-bit MUST be set to 0.

   This packet format works perfectly with xTRs that do not support Map-
   Versioning, since they can simply ignore those bits.  Furthermore,
   existing and future mapping distribution protocol (e.g., ALT
   [I-D.ietf-lisp-alt]) are able to carry version numbers without
   needing any modification.  The same applies to the LISP Map Server
   ([I-D.ietf-lisp-ms]), which will still work without any change since
   reserved bits are simply ignored.

8.  Benefits and case studies for Map-Versioning

   In the following sections we provide more discussion on various
   aspects and use of the Map-Versioning.  Security observations are
   instead grouped in Section 10.

8.1.  Synchronization of different xTRs

   Map-Versioning does not require additional synchronization mechanism
   compared to the normal functioning of LISP without Map-Versioning.
   Clearly all the ETRs have to reply with the same Map-Version number,
   otherwise there can be an inconsistency that creates additional
   control traffic, instabilities, traffic disruptions.  It is the same
   without Map-Versioning, with ETRs that have to reply with the same
   mapping, otherwise the same problems can arise.

   As an example, let's consider the topology of Figure 1 where ITR A.1
   of domain A is sending unidirectional traffic to the domain B, while
   A.2 of domain A exchange bidirectional traffic with domain B. In
   particular, ITR A.2 send traffic to ETR B and ETR A.2 receives
   traffic from ITR B.

    +-----------------+              +-----------------+
    | Domain A        |              | Domain B        |
    |       +---------+              |                 |
    |       | ITR A.1 |---           |                 |
    |       +---------+    \         +---------+       |
    |                 |      ------->| ETR B   |       |
    |                 |      ------->|         |       |
    |       +---------+    /         |         |       |
    |       | ITR A.2 |---      -----| ITR B   |       |
    |       |         |       /      +---------+       |
    |       | ETR A.2 |<-----        |                 |
    |       +---------+              |                 |
    |                 |              |                 |
    +-----------------+              +-----------------+

                                 Figure 1

   Obviously in the case of Map-Versioning both ITR A.1 and ITR A.2 of
   domain A must use the same value otherwise the ETR of domain B will
   start to send Map-Requests.

   The same problem can, however, arise without Map-Versioning.  For
   instance, if the two ITRs of domain A send different Loc Status Bits.
   In this case either the traffic is disrupted, if the ETR B trusts the
   Locator Status Bits, or if ETR B does not trusts the Locator Status
   Bits it will start sending Map-Requests to confirm the each change in
   the reachability.

   So far, LISP does not provide any specific synchronization mechanism,
   but assumes that synchronization is provided by configuring the
   different xTRs consistently.  The same applies for Map-Versioning.
   If in the future any synchronization mechanism is provided, Map-
   Versioning will take advantage of it automatically since it is
   included in the Record format, as described in Section 7.

8.2.  Map-Versioning and unidirectional traffic

   When using Map-Versioning the LISP specific header carries two Map-
   Version numbers, for both source and destination mappings.  This can
   raise the question on what will happen in the case of unidirectional
   flows, like for instance in the case presented in Figure 2, since
   LISP specification do not mandate for ETR to have a mapping for the
   source EID.

    +-----------------+            +-----------------+
    | Domain A        |            | Domain B        |
    |       +---------+            +---------+       |
    |       | ITR A   |----------->| ETR B   |       |
    |       +---------+            +---------+       |
    |                 |            |                 |
    +-----------------+            +-----------------+

                                 Figure 2

   For what concerns the ITR, it is able to put both source and
   destination version number in the LISP header since the Source Map-
   Version number is in ITR's database, while the Destination Map-
   Version number is in ITR's cache.

   For what concerns the ETR, it simply checks only the Destination Map-
   Version number in the same way as described in Section 5, ignoring
   the Source Map-Version number.

8.3.  Map-Versioning and interworking

   Map-Versioning is compatible with the LISP interworking between LISP
   and non-LISP sites as defined in [I-D.ietf-lisp-interworking].  LISP
   interworking defines three techniques to make LISP sites and non-LISP
   sites, namely Proxy-ITR, LISP-NAT, and Proxy-ETR.  Hereafter it is
   described how Map-Versioning relates to these three mechanisms.

8.3.1.  Map-Versioning and Proxy-ITRs

   The purpose of the Proxy-ITR (PITR) is to encapsulate traffic
   originating in a non-LISP site in order to deliver the packet to one
   of the ETRs of the LISP site (cf. Figure 3).  This case is very
   similar to the unidirectional traffic case described in Section 8.2,
   hence similar rules apply.

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ETR A |<-------| Proxy ITR |<-------|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

                                 Figure 3

   The main difference is that a Proxy-ITR does not have any mapping,
   since it just encapsulate packets arriving from non-LISP site, thus
   cannot provide a Source Map-Version.  In this case, the proxy-ITR
   will just put the Null Map-Version value as Source Map-Version
   number, while the receiving ETR will ignore the field.

   With this setup the LISP Domain A is able to check whether or not the
   PITR is using the latest mapping.  If this is not the case the
   mapping for LISP Domain A on the PITR can be updated using one of the
   mechanisms defined in [I-D.ietf-lisp] and
   [I-D.ietf-lisp-interworking].

8.3.2.  Map-Versioning and LISP-NAT

   The LISP-NAT mechanism is based on address translation from non-
   routable EIDs to routable EIDs and does not involve any form of
   encapsulation.  As such Map-Versioning does not apply in this case.

8.3.3.  Map-Versioning and Proxy-ETRs

   The purpose of the Proxy-ETR (PETR) is to decapsulate traffic
   originating in a LISP site in order to deliver the packet to the non-
   LISP site (cf. Figure 4).  One of the main reasons of deploy PETRs is
   to bypass uRPF (Unicast Reverse Path Forwarding) checks on the
   provider edge.

    +----------+                             +-------------+
    | LISP     |                             | non-LISP    |
    | Domain A |                             | Domain B    |
    |  +-------+        +-----------+        |             |
    |  | ITR A |------->| Proxy ETR |------->|             |
    |  +-------+        +-----------+        |             |
    |          |                             |             |
    +----------+                             +-------------+

                                 Figure 4

   A Proxy-ETR does not have any mapping, since it just decapsulate
   packets arriving from LISP site.  In this case, the ITR will just put
   the Null Map-Version value as Destination Map-Version number, while
   the receiving Proxy-ETR will ignore the field.

   With this setup the Proxy-ETR is able to check whether or not the
   mapping has changed.  If this is the case the mapping for LISP Domain
   A on the PETR can be updated using one of the mechanisms defined in
   [I-D.ietf-lisp] and [I-D.ietf-lisp-interworking].

8.4.  RLOC shutdown/withdraw

   Map-Versioning can be even used to perform a graceful shutdown or
   withdraw of a specific RLOC.  This is achieved by simply issuing a
   new mapping, with an updated Map-Version number, where the specific
   RLOC to be shut down is withdrawn or announced as unreachable (R bit
   in the Map Record, see [I-D.ietf-lisp]), but without actually turning
   it off.

   Once no more traffic is received by the RLOC, because all sites have
   updated the mapping, it can be shut down safely.

   It should be pointed out that for frequent up/down changes such a
   mechanism should not be used since this can generate excessive load
   on the Mapping System.

8.5.  Map-Version for lightweight LISP implementation

   The use of Map-Versioning can help in developing a lightweight
   implementation of LISP.  This comes with the price of not supporting
   Loc-Status-Bit, which are useful in some contexts.

   In the current LISP specifications the set of RLOCs must always be
   maintained ordered and consistent with the content of the Loc Status
   Bits (see section 6.5 of [I-D.ietf-lisp]).  With Map-Versioning such
   type of mechanisms can be avoided.  When a new RLOC is added to a
   mapping, it is not necessary to "append" new locators to the existing
   ones as explained in Section 6.5 of [I-D.ietf-lisp].  A new mapping
   with a new Map-Version number will be issued, and since the old
   locators are still valid the transition will be with no disruptions.
   The same applies for the case a RLOC is withdrawn.  There is no need
   to maintain holes in the list of locators, as is the case when using
   Locator Status Bits, for sites that are not using the RLOC that has
   been withdrawn the transition will be with no disruptions.

   All of these operations, as already stated, do not need to maintain
   any consistency among Locator Status Bits, and the way RLOC are
   stored in the cache.

   Further, Map-Version can be used to substitute the "clock sweep"
   operation described in Section 6.5.1 of [I-D.ietf-lisp].  Indeed,
   every LISP site communicating to a specific LISP site that has
   updated the mapping will be informed of the available new mapping in
   a data-driven manner.

   Note that what is proposed in the present section is just a case study an example
   and MUST NOT be considered as specification specifications for a lightweight LISP
   implementation.  In case the IETF decides to undertake such a work,
   it will be documented elsewhere.

9.  Incremental deployment and implementation status

   Map-Versioning can be incrementally deployed without any negative
   impact on existing LISP elements (e.g., xTRs, Map-Servers, Proxy-
   ITRs, etc).  Any LISP element that does not support Map-Versioning
   can safely ignore them.  Further, there is no need of any specific
   mechanism to discover if an xTR supports or not Map-Versioning.  This
   information is already included in the Map Record.

   Map-Versioning is currently implemented in OpenLISP
   [I-D.iannone-openlisp-implementation].

   Note that the reference document for LISP implementation and
   interoperability tests remains [I-D.ietf-lisp].

10.  Security Considerations

   Map-Versioning does not introduce any new security issue concerning
   both the data-plane and the control-plane.  On the contrary, as
   described in the following, if Map-Versioning may be used also to
   update mappings in case of change in the reachability information
   (i.e., instead of the Locator Status Bits) it is possible to reduce
   the effects of some DoS or spoofing attacks that can happen in an
   untrusted environment.

   A thorough security analysis of LISP is documented in
   [I-D.saucez-lisp-security].
   [I-D.ietf-lisp-threats].

10.1.  Map-Versioning against traffic disruption

   An attacker can try to disrupt ongoing communications by creating
   LISP encapsulated packets with wrong Locator Status Bits.  If the xTR
   blindly trusts the Locator Status Bits it will change the
   encapsulation accordingly, which can result in traffic disruption.

   This does not happen in the case of Map-Versioning.  As described in
   Section 5, upon a version number change the xTR first issues a Map-
   Request.  The assumption is that the mapping distribution system is
   sufficiently secure that Map-Request and Map-Reply messages and their
   content can be trusted.  Security issues concerning specific mapping
   distribution system are out of the scope of this document.  In the
   case of Map-Versioning the attacker should "guess" a valid version
   number that triggers a Map-Request, as described in Section 5,
   otherwise the packet is simply dropped.  Nevertheless, guessing a
   version number that generates a Map-Request is easy, hence it is
   important to follow the rate limitations policies described in
   [I-D.ietf-lisp] in order to avoid DoS attacks.

   Note that a similar level of security can be obtained with Loc Status
   Bits, by simply making mandatory to verify any change through a Map-
   Request.  However, in this case Locator Status Bits loose their
   meaning, because, it does not matter anymore which specific bits has
   changed, the xTR will query the mapping system and trust the content
   of the received Map-Reply.  Furthermore there is no way to perform
   filtering as in the Map-Versioning in order to drop packets that do
   not carry a valid Map-Version number.  In the case of Locator Status
   Bits, any random change can trigger a Map-Request (unless rate
   limitation is enabled which raise another type of attack discussed in
   Section 10.2).

10.2.  Map-Versioning against reachability information DoS

   Attackers can try to trigger a large amount of Map-Request by simply
   forging packets with random Map-Version or random Locator Status
   Bits.  In both cases the Map-Requests are rate limited as described
   in [I-D.ietf-lisp].  However, differently from Locator Status Bit
   where there is no filtering possible, in the case of Map-Versioning
   is possible to filter not valid version numbers before triggering a
   Map-Request, thus helping in reducing the effects of DoS attacks.  In
   other words the use of Map-Versioning enables a fine control on when
   to update a mapping or when to notify that a mapping has been
   updated.

   It is clear, that Map-Versioning does not protect against DoS and
   DDoS attacks, where an xTR looses processing power doing checks on
   the LISP header of packets sent by attackers.  This is independent
   from Map-Versioning and is the same for Loc Status Bits.

11.  IANA Considerations

   This document has no actions for IANA.

12.  Acknowledgements

   The authors would like to thank Alia Atlas, Jesper Skriver, Pierre
   Francois, Noel Chiappa, Dino Farinacci for their comments and review.

   This work has been partially supported by the INFSO-ICT-216372
   TRILOGY Project (www.trilogy-project.org).

13.  References

13.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-10
              draft-ietf-lisp-14 (work in progress), March June 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [I-D.iannone-openlisp-implementation]
              Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
              Implementation Report",
              draft-iannone-openlisp-implementation-01 (work in
              progress), July 2008.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 draft-ietf-lisp-alt-07
              (work in progress), March June 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01
              draft-ietf-lisp-interworking-02 (work in progress),
              August 2010.
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-06
              draft-ietf-lisp-ms-09 (work in progress), October 2010.

   [I-D.saucez-lisp-security] June 2011.

   [I-D.ietf-lisp-threats]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP
              Security Threats", draft-saucez-lisp-security-02 Threats
              Analysis", draft-ietf-lisp-threats-00 (work in progress), January
              July 2011.

Appendix A.  Estimation of time before Map-Version wrap-around

   The present section proposes an estimation of the wrap-around time
   for the proposed 12 bits size for the Map-Version number.  Using a
   granularity of seconds and assuming as worst-case that a new version
   is issued each second, it takes slightly more than 1 hour before the
   version wraps around.  Note that the granularity of seconds is in
   line with the rate limitation policy for Map-Request messages, as
   proposed in the LISP main specifications ([I-D.ietf-lisp]).
   Alternatively a granularity of minutes can also be used, as for the
   TTL of the Map-Reply ([I-D.ietf-lisp]).  In this case the worst
   scenario is when a new version is issued every minute, leading to a
   much longer time before wrap-around.  In particular, when using 12
   bits, the wrap-around time is almost 3 days.

   For general information, hereafter there is a table with a rough
   estimation of the time before wrap-around in the worst-case scenario,
   considering different sizes (bits length) of the Map-Version number
   and different time granularity.

   +---------------+--------------------------------------------+
   |Version Number |           Time before wrap around          |
   |  Size (bits)  +---------------------+----------------------+
   |               |Granularity: Minutes | Granularity: Seconds |
   |               | (mapping changes    | (mapping changes     |
   |               |  every 1 minute)    |  every 1 second)     |
   +-------------------------------------+----------------------+
   |          32   |   8171   Years      |  136   Years         |
   |          30   |   2042   Years      |   34   Years         |
   |          24   |     31   Years      |  194   Days          |
   |          16   |     45   Days       |   18   Hours         |
   |          15   |     22   Days       |    9   Hours         |
   |          14   |     11   Days       |    4   Hours         |
   |          13   |      5.6 Days       |    2.2 Hours         |
   |          12   |      2.8 Days       |    1.1 Hours         |
   +---------------+---------------------+----------------------+

              Figure 5: Estimation of time before wrap-around

Appendix B.  Document Change Log

   o  Version 02 Posted July 2011.

      *  Added text in Section 5 about ETR synchronization, as suggested
         by Alia Atlas.

      *  Modified text in Section 8.5 concerning lightweight LISP
         implementation, as suggested by Alia Atlas.

      *  Deleted text concerning old versions of [I-D.ietf-lisp-ms] and
         [I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas.

      *  Fixed section 4.1 to be less restrictive, as suggested by
         Jesper Skriver.

   o  Version 01 Posted March 2011.

      *  Changed the wording from "Map-Version number 0" to "Null Map-
         Version.

      *  Clarification of the use of the Null Map-Version value as
         Source Map-Version Number and Destination Map-Version Number.

      *  Extended the section describing Map-Versioning and LISP
         Interworking co-existence.

      *  Reduce packet format description to avoid double definitions
         with the main specs.

   o  Version 00 Posted September 2010.

      *  Added Section "Definitions of Terms".

      *  Editorial polishing of all sections.

      *  Added clarifications in section "Dealing with Map-Version
         numbers" for the case of the special Map-Version number 0.

      *  Rename of draft-iannone-mapping-versioning-02.txt.

Authors' Addresses

   Luigi Iannone
   TU Berlin - Deutsche Telekom Laboratories AG
   Ernst-Reuter Platz 7
   Berlin
   Germany

   Email: luigi@net.t-labs.tu-berlin.de

   Damien Saucez
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain la Neuve
   Louvain-la-Neuve
   Belgium

   Email: damien.saucez@uclouvain.be

   Olivier Bonaventure
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain la Neuve
   Louvain-la-Neuve
   Belgium

   Email: olivier.bonaventure@uclouvain.be
--Apple-Mail-5-855919706 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail-5-855919706-- --Apple-Mail-4-855919705-- From internet-drafts@ietf.org Thu Jul 7 11:14:06 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AABE21F8895; Thu, 7 Jul 2011 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljtlKBtc6xRl; Thu, 7 Jul 2011 11:14:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98E21F8884; Thu, 7 Jul 2011 11:14:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110707181405.16299.95519.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 11:14:05 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:14:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-10.txt Pages : 19 Date : 2011-07-07 This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge&= quot; of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-10.txt From vaf@cisco.com Thu Jul 7 11:28:28 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDC1F0C6F for ; Thu, 7 Jul 2011 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=-3.940, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHexDmfTg1lC for ; Thu, 7 Jul 2011 11:28:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A7EBA1F0C5D for ; Thu, 7 Jul 2011 11:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=1447; q=dns/txt; s=iport; t=1310063307; x=1311272907; h=date:from:to:subject:message-id:mime-version; bh=A9O5YTa31tdsSY247hP4IsRnWBgrrKXKnr/yv0o6YCw=; b=IHco1ayIuITl43l+tzjDP/+nD4EL98JVVMAc3gvFh269Jz7ZxP47SNLp aKrrlBe+qodAtaRDFtv6f5S+WnoSadbbitzBm/fo+BCLQX0kRzRCMp5Yg O0W8rV8l0usdbfkhxSnTgYUcy4wdMvsbrvcLZdxUVN/Ri6a8C8thUYgzw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0HABj6FU6rRDoI/2dsb2JhbABTmEGOdHesNIEinXiGOASHSZte X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="766874" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jul 2011 18:28:27 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67ISQSa016717 for ; Thu, 7 Jul 2011 18:28:26 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 8390312F4D65; Thu, 7 Jul 2011 11:28:25 -0700 (PDT) Date: Thu, 7 Jul 2011 11:28:25 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20110707182825.GA66089@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: New Version Notification for draft-ietf-lisp-ms-10.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:28:28 -0000 Only change is to update the reference for SHA from RFC 4634 to RFC 6234. This resolves the single open "IDNIT" for this document. --Vince ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 07 Jul 2011 11:14:06 -0700 From: internet-drafts@ietf.org To: vaf@cisco.com Cc: vaf@cisco.com, dino@cisco.com Subject: New Version Notification for draft-ietf-lisp-ms-10.txt A new version of I-D, draft-ietf-lisp-ms-10.txt has been successfully submitted by Vince Fuller and posted to the IETF repository. Filename: draft-ietf-lisp-ms Revision: 10 Title: LISP Map Server Creation date: 2011-07-07 WG ID: lisp Number of pages: 19 Abstract: This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map Server is to reduce implementation and operational complexity of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. The IETF Secretariat ----- End forwarded message ----- From internet-drafts@ietf.org Sat Jul 9 10:30:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893C21F86E8; Sat, 9 Jul 2011 10:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhpNAmnt2vhX; Sat, 9 Jul 2011 10:30:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A3521F8674; Sat, 9 Jul 2011 10:30:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709173000.28573.16478.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 10:30:00 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-15.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:30:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Locator/ID Separation Protocol (LISP) Author(s) : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Filename : draft-ietf-lisp-15.txt Pages : 90 Date : 2011-07-09 This draft describes a network-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits even to early adopters, when there are relatively few LISP- capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October, 2006 IAB Routing and Addressing Workshop. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-15.txt From internet-drafts@ietf.org Sat Jul 9 10:30:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB90221F88AF; Sat, 9 Jul 2011 10:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TWoCZSrWBqS; Sat, 9 Jul 2011 10:30:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A521F8674; Sat, 9 Jul 2011 10:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709173058.28613.66218.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 10:30:58 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-multicast-07.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:30:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP for Multicast Environments Author(s) : Dino Farinacci Dave Meyer John Zwiebel Stig Venaas Filename : draft-ietf-lisp-multicast-07.txt Pages : 37 Date : 2011-07-09 This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-multicast-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-multicast-07.txt From internet-drafts@ietf.org Sat Jul 9 10:31:59 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3344021F8601; Sat, 9 Jul 2011 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kerZvI-52pbi; Sat, 9 Jul 2011 10:31:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43CE21F85F8; Sat, 9 Jul 2011 10:31:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709173158.30342.35447.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 10:31:58 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lig-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 17:31:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Internet Groper (LIG) Author(s) : Dino Farinacci Dave Meyer Filename : draft-ietf-lisp-lig-03.txt Pages : 19 Date : 2011-07-09 A simple tool called the LISP Internet Groper or 'lig' can be us= ed to query the LISP mapping database. This draft describes how it works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-lig-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-lig-03.txt From dino@cisco.com Sun Jul 10 15:42:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6C221F8588 for ; Sun, 10 Jul 2011 15:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-6.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXkmXKnVyZOO for ; Sun, 10 Jul 2011 15:42:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7B21F8586 for ; Sun, 10 Jul 2011 15:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=5505; q=dns/txt; s=iport; t=1310337769; x=1311547369; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date:cc; bh=20/A6Z2yXqHHGO9J/nPwoUuOHzSfQ0EHHrGPlBtel+k=; b=M3dLVIolRmK9CfVVBmvjfze85hAcjxzwxpsWld5LedVpupwnRukFz8PU aOr6HzYy8CCteTyOeDaJGtPuSXtlPbnDunsNMGUgrCEc99SmLyWovaMEi VSS4ttvOgPHHKxrffXzqr6wGpLhgaKUl7Ggr1eKxMXX2OF/vQfnsR7OoV 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFQqGk6rRDoG/2dsb2JhbABTpz13iHqiDJ0ZhVtfBIdOiwaEfotp X-IronPort-AV: E=Sophos;i="4.65,510,1304294400"; d="scan'208";a="1538052" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jul 2011 22:42:48 +0000 Received: from [192.168.1.3] (sjc-vpn5-9.cisco.com [10.21.88.9]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6AMgmPC018153; Sun, 10 Jul 2011 22:42:48 GMT Message-Id: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> From: Dino Farinacci To: jsw@inconcepts.biz Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 10 Jul 2011 15:42:48 -0700 X-Mailer: Apple Mail (2.936) Cc: nanog@nanog.org, lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 22:42:50 -0000 > From: Jeff Wheeler > Date: July 10, 2011 1:43:40 PM PDT > To: NANOG > Subject: Re: Anybody can participate in the IETF (Was: Why is IPv6 > broken?) I am not on the Nanog mailing list but a friend forwarded this to me. I would like to respond to your LISP comments Jeff. See responses inline. I have copied the lisp@ietf.org mailing list. > On Sun, Jul 10, 2011 at 3:45 PM, Owen DeLong wrote: >> Number two: While anyone can participate, approaching IETF as an >> operator requires a rather thick skin, or, at least it did the last >> couple >> of times I attempted to participate. I've watched a few times where > > I am subscribed to the IDR (BGP, etc.) and LISP lists. These are > populated with different people and cover entirely different topics. > My opinion is the following: > > * The IDR list is welcoming of operators, but whether or not your > opinion is listened to or included in the process, I do not know. > Randy Bush, alone, posts more on this list than the sum of all > operators who post in the time I've been reading. I think Randy's > influence is 100% negative, and it concerns me deeply that one > individual has the potential to do so much damage to essential > protocols like BGP. Also, the priorities of this list are pretty > fucked. Inaction within this working group is the reason we still > don't have expanded BGP communities for 32 bit ASNs. The reason for > this is operators aren't participating. The people on the list or the > current participants of the WG should not be blamed. My gripe about > Randy Bush having the potential to do huge damage would not exist if > there were enough people on the list who understand what they're doing > to offer counter-arguments. > >> operators were shouted down by purists and religion over basic >> real-world operational concerns. It seems to be a relatively routine >> practice and does not lead to operators wanting to come back to >> an environment where they feel unwelcome. > > I have found my input on the LISP list completely ignored because, as > you suggest, my concerns are real-world and don't have any impact on > someone's pet project. LISP as it stands today can never work on the I bet your concerns are real-world but there are a lot of reasons why there is a lack of response on mailing lists. Maybe a lot is going on at the time or people are too busy to respond. But we, the LISP authors take input very seriously. I can speak for myself, we do not want to ignore the mailing list. It is the mailing list that has brought LISP to where it is today. And many are grateful of that. If you could please restate on the list what your concerns are, we can have a discussion. > Internet, and regardless of the fine reputations of the people at > Cisco and other organizations who are working on it, they are either > furthering it only because they would rather work on a pet project > than something useful to customers, or because they truly cannot Many of us have been working on the Internet for a very long time. We do so because we have passion to keep growing and scaling it. That is a basic fact. If you think that sounds cliche, then I am sorry for that. But, at least for me, it is simple as that. > understand its deep, insurmountable design flaws at Internet-scale. > You would generally hope that someone saying, "LISP can't work at > Internet-scale because anyone will be able to trivially DoS any LISP > ITR ('router' for simplicity), Many have made this comment and that is why we have been working hard on cache management to see, if in practice, this is a real problem. The Internet has caches all over the place, some have proven to work extremely well and the Internet would not be at the scale it is today without them. Many researchers have looked at ITR caching and there are papers published that discuss pros and cons. > but here is a way you can improve it," > well, that remark, input, and person should be taken quite seriously, What data do you have that it was not taken seriously? > their input examined, and other assumptions about the way LISP is > supposed to work ought to be questioned. None of this has happened. The main spec has gone through 29 revisions. LISP have been in review for 4 years both in the IRTF and the IETF. There is a pilot network with approximately 120 boxes in 25 countries. This is a very serious undertaking. There are real resources and real dollars going into this. > LISP is a pet project to get some people their Ph.D.s and keep some People will get their Ph.D's from all kinds of networking research. That is the nature of the beast and of course not specific to LISP. > old guard vendor folks from jumping ship to another company. It is a > shame that the IETF is manipulated to legitimize that kind of thing. Both points are hard to comment on without being negative. And I don't want to be negative. I want to take your comments as constructive and start a technical discussion on your concerns. > Then again, I could be wrong. Randy Bush could be a genius and LISP > could revolutionize mobility. We are all wrong and we are all right. Let's start the technical discussion. Thanks, Dino > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From jsw@inconcepts.biz Sun Jul 10 16:47:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D29E21F877A for ; Sun, 10 Jul 2011 16:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxgufYbM9VHU for ; Sun, 10 Jul 2011 16:47:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75C7821F8766 for ; Sun, 10 Jul 2011 16:47:32 -0700 (PDT) Received: by vws12 with SMTP id 12so3528118vws.31 for ; Sun, 10 Jul 2011 16:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.38.130 with SMTP id b2mr1278873vce.184.1310341651360; Sun, 10 Jul 2011 16:47:31 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Sun, 10 Jul 2011 16:47:31 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> Date: Sun, 10 Jul 2011 19:47:31 -0400 Message-ID: From: Jeff Wheeler To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 23:47:33 -0000 On Sun, Jul 10, 2011 at 6:42 PM, Dino Farinacci wrote: > or people are too busy to respond. But we, the LISP authors take input ve= ry > seriously. I can speak for myself, we do not want to ignore the mailing I suggest you read my post, linked below, discussing cache management vulnerabilities, and a way to improve upon them. Darrel Lewis is the only person who has showed any interest in this at all, and there has been essentially zero public discussion of it. I have also swapped email with the authors of the lisp-threats draft, who believe this problem warrants precisely one vague sentence. http://www.ietf.org/mail-archive/web/lisp/current/msg02949.html You can imagine how my view of LISP as a pet project, consuming vendor personnel / resources on something which may have, at best, VPN application, came about. This is a very obvious problem with a great deal of history -- many of the people I see working on LISP have been around since flow-cache routing was popular, and unpopular, certainly including yourself. Some have not been and have yet to learn some of the lessons from the 90s. > Many researchers have looked at ITR caching and there are papers publishe= d > that discuss pros and cons. An academic paper examining 20k macro-flows toward ETRs is far from Internet-scale, and is in my opinion not useful. Perhaps I have not read some more recent work on this topic; but all the LISP-specific "research" I've seen in this area is nothing more than C.V. padding. It can easily be shown that an ITR must have a huge FIB, compared to FIB sizes today, in order to operate normally under a DDoS designed to exploit the vulnerable negative mapping cache, which must be able to install same mappings into FIB to guard the control-plane against excessive punts, or avoid simply dropping punts which would cause resolution of mappings for positive/good destination mappings. Again, see my mailing list post. > We are all wrong and we are all right. Let's start the technical discussi= on. I welcome such discussion. LISP is very much designed from an "eyeball" perspective, with the intent of delivering increased traffic engineering capabilities, and multi-homed connectivity, to SOHO-type networks with less expensive hardware. The impact of this is, quite simply, a shift of cost to the datacenter / content network, or a shift of complexity to the actual content server, which may, and probably should, become an ITR itself to avoid scaling problems with ITRs in mixed-use datacenters. Making it cheaper and easier to multi-home a SOHO network must ultimately have the affect of dramatically increasing the number of such networks which are multi-homed. Not only is current LISP work viewing the number of destination networks as substantially fewer than those which already exist today -- it does not even attempt to account for this growth. It certainly does not account for the possibility of DoS designed to exploit cache churn. Even without any significant increase in the number of destination networks today, and if you assumed each ASN had only one ETR (obviously that will not be true), if LISP were really deployed widely across the Internet, an ITR would need about 500k FIB slots to manage just 50k destination networks, given current IPv6 addressing strategy. An ETR intending to check the origin of traffic before admitting it to the network will encounter a similar problem. These problems are obvious. Improvements can be made, but this has not been done, and as far as I can tell, it has not been seriously discussed. A test network is certainly useful to discover emergent problems and implementation issues, but from my perspective, feeling a little proud about having a pilot network deployed while gaping protocol design problems are not being addressed is a deeply misguided waste of time and resources. Scaling problems with ITR caches can be shown with simple arithmetic -- they do not even require a working router to discover. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From dino@cisco.com Sun Jul 10 21:29:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949FD21F8870 for ; Sun, 10 Jul 2011 21:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-3.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19UTi5YD54VO for ; Sun, 10 Jul 2011 21:29:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08721F86A5 for ; Sun, 10 Jul 2011 21:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=6860; q=dns/txt; s=iport; t=1310358570; x=1311568170; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=qSKjri2l3PpmaL9eONotyhE4hY98yUUif9EuneXdOrA=; b=SSmOwk+R5sppCd8xtX2ZaoO/bHDPxvlKQkVdztAS5/ft8FqnRhDwVM+M WFuLpySC8mcGmIv7dL5B/UHNn3F30FSuiFlLWgd9MNu6Nvynye3xj9juv NrDpBszH9+cIhXKcZTpnO2Y8ncGEhmCVZI2epu3FicWZXStl9RinyU2Qv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADB7Gk6rRDoG/2dsb2JhbABTpz13iHqhJp00gzWCJl8Eh06LBoR+i2k X-IronPort-AV: E=Sophos;i="4.65,512,1304294400"; d="scan'208";a="1579757" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2011 04:29:29 +0000 Received: from [172.20.10.2] (sjc-vpn4-422.cisco.com [10.21.81.166]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6B4TJ5B022414; Mon, 11 Jul 2011 04:29:27 GMT Message-Id: <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> From: Dino Farinacci To: Jeff Wheeler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 10 Jul 2011 21:29:17 -0700 References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> X-Mailer: Apple Mail (2.936) Cc: nanog@nanog.org, lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 04:29:31 -0000 > On Sun, Jul 10, 2011 at 6:42 PM, Dino Farinacci > wrote: >> or people are too busy to respond. But we, the LISP authors take >> input very >> seriously. I can speak for myself, we do not want to ignore the >> mailing > > I suggest you read my post, linked below, discussing cache management > vulnerabilities, and a way to improve upon them. Darrel Lewis is the > only person who has showed any interest in this at all, and there has Oh so you did get a response. You gave the impression you were ignored. > been essentially zero public discussion of it. I have also swapped > email with the authors of the lisp-threats draft, who believe this > problem warrants precisely one vague sentence. Have you looked at the latest draft. We have added more in this area. > http://www.ietf.org/mail-archive/web/lisp/current/msg02949.html > > You can imagine how my view of LISP as a pet project, consuming vendor > personnel / resources on something which may have, at best, VPN > application, came about. This is a very obvious problem with a great > deal of history -- many of the people I see working on LISP have been > around since flow-cache routing was popular, and unpopular, certainly > including yourself. Some have not been and have yet to learn some of > the lessons from the 90s. An ITR does not maintain a flow-cache. A LISP cache can get as large as a BGP cache if the site is sending to every destination in the Internet. Probabilistically that won't happen. But routers do have finite memory so even today the BGP cache can exceed the physical capacity of the device. The problems of the 90s are much different that what is going on there. I was there. With a on-demand cache you can limit who you talk to. With a BGP cache, you could do the same thing. There really is no different. Any implementor experienced in the art, will tell you the same resources are used and the same table management techniques would have to be used. The size of the LISP cache will usually be less than or equal to a BGP cache. When comparing apples to apples it is the same. If you think the LISP will have more granular prefixes, say you put host routes in it, it will be as large as BGP with host routes. The reason I am going this way is to indicate that any data structure can be abused. >> Many researchers have looked at ITR caching and there are papers >> published >> that discuss pros and cons. > > An academic paper examining 20k macro-flows toward ETRs is far from > Internet-scale, and is in my opinion not useful. Perhaps I have not Okay, so put 350K in it. What is your point. Give me a technical point and not that we didn't make the test large enough. > read some more recent work on this topic; but all the LISP-specific > "research" I've seen in this area is nothing more than C.V. padding. > > It can easily be shown that an ITR must have a huge FIB, compared to > FIB sizes today, in order to operate normally under a DDoS designed to It can be easily shown that it doesn't. And this week it will be publicly presented that the FIB cache can be over-subscribed when LISP is used. > exploit the vulnerable negative mapping cache, which must be able to > install same mappings into FIB to guard the control-plane against > excessive punts, or avoid simply dropping punts which would cause > resolution of mappings for positive/good destination mappings. Again, > see my mailing list post. Punting will always be a problem until data-planes can create state. But it is not a show-stopper. >> We are all wrong and we are all right. Let's start the technical >> discussion. > > I welcome such discussion. LISP is very much designed from an > "eyeball" perspective, with the intent of delivering increased traffic > engineering capabilities, and multi-homed connectivity, to SOHO-type > networks with less expensive hardware. The impact of this is, quite > simply, a shift of cost to the datacenter / content network, or a > shift of complexity to the actual content server, which may, and > probably should, become an ITR itself to avoid scaling problems with > ITRs in mixed-use datacenters. Right. It is time to experiment with state in a few places rather than everywhere. > Making it cheaper and easier to multi-home a SOHO network must > ultimately have the affect of dramatically increasing the number of > such networks which are multi-homed. Not only is current LISP work > viewing the number of destination networks as substantially fewer than > those which already exist today -- it does not even attempt to account > for this growth. Yes, but that growth will not affect the core capacity. > It certainly does not account for the possibility of DoS designed to > exploit cache churn. Even without any significant increase in the With the mapping database, we can push back attacks to the source. That has only been tried with source-quench for congestion control. > number of destination networks today, and if you assumed each ASN had > only one ETR (obviously that will not be true), if LISP were really > deployed widely across the Internet, an ITR would need about 500k FIB > slots to manage just 50k destination networks, given current IPv6 I don't know what you mean, but if your definition of a 'destination network' is either a single or multi-homed site, then the FIB would hold 50K entries. > addressing strategy. An ETR intending to check the origin of traffic > before admitting it to the network will encounter a similar problem. Should a router today check origin before admitting traffic? If not, why not? Why does LISP require it where a CPE router today not? And by the way those routers as well as routers running LISP to run with uRPF configured. > These problems are obvious. Improvements can be made, but this has They are problems but not the end of the world. Why you think they are serious I am not sure. > not been done, and as far as I can tell, it has not been seriously > discussed. A test network is certainly useful to discover emergent Have you been to the LISP working group meetings? This has been discussed many times. > problems and implementation issues, but from my perspective, feeling a > little proud about having a pilot network deployed while gaping > protocol design problems are not being addressed is a deeply misguided > waste of time and resources. Scaling problems with ITR caches can be > shown with simple arithmetic -- they do not even require a working > router to discover. Then show me the simple arithmetic. Dino > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From jsw@inconcepts.biz Sun Jul 10 21:57:21 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3546721F8687 for ; Sun, 10 Jul 2011 21:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPABtEF-bXV4 for ; Sun, 10 Jul 2011 21:57:20 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52421F8685 for ; Sun, 10 Jul 2011 21:57:20 -0700 (PDT) Received: by vws12 with SMTP id 12so3678613vws.31 for ; Sun, 10 Jul 2011 21:57:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.12.137 with SMTP id x9mr1320418vcx.149.1310360239732; Sun, 10 Jul 2011 21:57:19 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Sun, 10 Jul 2011 21:57:19 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> Date: Mon, 11 Jul 2011 00:57:19 -0400 Message-ID: From: Jeff Wheeler To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 04:57:21 -0000 On Mon, Jul 11, 2011 at 12:29 AM, Dino Farinacci wrote: > I don't know what you mean, but if your definition of a 'destination > network' is either a single or multi-homed site, then the FIB would hold = 50K > entries. I am not responding to all of the points raised in your message, because you are still missing the fundamental problem that negative replies from the LISP Mapping Service, which should be cached in the ITR, can cause the table to be inflated to a size that is, literally, ten times the number of possible positive mapping entries. Once again, read my original LISP mailing list post on this subject. If you read the part in the MS draft that dictates negative replies must not overlap any possible positive mappings, and consider how RIRs are currently allocating IPv6 address space to networks, you should easily realize how this part of the MS protocol needs additional flexibility. Quite simply, a 50k entry IPv6 table would indeed consume 500k entries when negative entries are included. The simple arithmetic is in my original post, months ago. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From luigi@net.t-labs.tu-berlin.de Mon Jul 11 02:52:44 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4302121F852B for ; Mon, 11 Jul 2011 02:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpTc55ckeg59 for ; Mon, 11 Jul 2011 02:52:43 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51321F8567 for ; Mon, 11 Jul 2011 02:52:24 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 1B2D6701F36C; Mon, 11 Jul 2011 11:52:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Mon, 11 Jul 2011 11:52:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <433A9A5F-A7E1-4FEA-8154-5F5AC48B4871@net.t-labs.tu-berlin.de> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:52:44 -0000 On Jul 11, 2011, at 01:47 , Jeff Wheeler wrote: > On Sun, Jul 10, 2011 at 6:42 PM, Dino Farinacci = wrote: >> or people are too busy to respond. But we, the LISP authors take = input very >> seriously. I can speak for myself, we do not want to ignore the = mailing >=20 > I suggest you read my post, linked below, discussing cache management > vulnerabilities, and a way to improve upon them. Darrel Lewis is the > only person who has showed any interest in this at all, and there has > been essentially zero public discussion of it. I have also swapped > email with the authors of the lisp-threats draft, who believe this > problem warrants precisely one vague sentence. >=20 As co-author of that draft, let me say that we acknowledged the problem = and proposed to you to add more wording on it, but you were still = unhappy. As we told you in our email exchange, the threat draft if is just an = analysis. It is not the place where LISP specification should be = changed.=20 Indeed in your original email you refer to draft-ietf-lisp-ms-07, why = should we modify the security analysis draft? We suggested you that if you feel the problem so important to jeopardize = any further LISP deployment just come to the IETF and discuss with us. = What would be very helpful is to focus on the technical part and help in = design a solution. Let's avoid this continuos "LISP is a pet project", "LISP is broken", = etc etc.... this is useless discussion.=20 > http://www.ietf.org/mail-archive/web/lisp/current/msg02949.html >=20 > You can imagine how my view of LISP as a pet project, consuming vendor > personnel / resources on something which may have, at best, VPN > application, came about. IMHO, you fail to see the real potential of LISP. > This is a very obvious problem with a great > deal of history -- many of the people I see working on LISP have been > around since flow-cache routing was popular, and unpopular, certainly > including yourself. Some have not been and have yet to learn some of > the lessons from the 90s. >=20 >> Many researchers have looked at ITR caching and there are papers = published >> that discuss pros and cons. >=20 > An academic paper examining 20k macro-flows toward ETRs is far from > Internet-scale, and is in my opinion not useful. I am not sure which paper you refer to, but AFAIR there is no paper with = 20K "macro-flows". > Perhaps I have not > read some more recent work on this topic; but all the LISP-specific > "research" I've seen in this area is nothing more than C.V. padding. >=20 This is just your personal opinion not the truth. =20 Luigi > It can easily be shown that an ITR must have a huge FIB, compared to > FIB sizes today, in order to operate normally under a DDoS designed to > exploit the vulnerable negative mapping cache, which must be able to > install same mappings into FIB to guard the control-plane against > excessive punts, or avoid simply dropping punts which would cause > resolution of mappings for positive/good destination mappings. Again, > see my mailing list post. >=20 >> We are all wrong and we are all right. Let's start the technical = discussion. >=20 > I welcome such discussion. LISP is very much designed from an > "eyeball" perspective, with the intent of delivering increased traffic > engineering capabilities, and multi-homed connectivity, to SOHO-type > networks with less expensive hardware. The impact of this is, quite > simply, a shift of cost to the datacenter / content network, or a > shift of complexity to the actual content server, which may, and > probably should, become an ITR itself to avoid scaling problems with > ITRs in mixed-use datacenters. >=20 > Making it cheaper and easier to multi-home a SOHO network must > ultimately have the affect of dramatically increasing the number of > such networks which are multi-homed. Not only is current LISP work > viewing the number of destination networks as substantially fewer than > those which already exist today -- it does not even attempt to account > for this growth. >=20 > It certainly does not account for the possibility of DoS designed to > exploit cache churn. Even without any significant increase in the > number of destination networks today, and if you assumed each ASN had > only one ETR (obviously that will not be true), if LISP were really > deployed widely across the Internet, an ITR would need about 500k FIB > slots to manage just 50k destination networks, given current IPv6 > addressing strategy. An ETR intending to check the origin of traffic > before admitting it to the network will encounter a similar problem. >=20 > These problems are obvious. Improvements can be made, but this has > not been done, and as far as I can tell, it has not been seriously > discussed. A test network is certainly useful to discover emergent > problems and implementation issues, but from my perspective, feeling a > little proud about having a pilot network deployed while gaping > protocol design problems are not being addressed is a deeply misguided > waste of time and resources. Scaling problems with ITR caches can be > shown with simple arithmetic -- they do not even require a working > router to discover. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Mon Jul 11 03:01:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFB321F8AB0 for ; Mon, 11 Jul 2011 03:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgbU9C905A98 for ; Mon, 11 Jul 2011 03:01:23 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 7183621F85F3 for ; Mon, 11 Jul 2011 03:01:23 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id AA8AF7000585; Mon, 11 Jul 2011 12:01:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Mon, 11 Jul 2011 12:01:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59EFA289-F796-4803-B95E-39FBB12E270B@net.t-labs.tu-berlin.de> References: To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:01:24 -0000 Jeff, from your original post. On Apr 28, 2011, at 07:31 , Jeff Wheeler wrote: > Dear List, >=20 > I've had several off-list discussions with some vendor folks, and > otherwise, working hard on LISP. I see that the issue of cache > thrashing is currently left entirely up to the implementor to handle. > I may be unaware of some body of work on this topic, however, I > believe the current language in draft-ietf-lisp-ms-07, below, > eliminates a needed means of reducing negative mapping cache size on > an ITR. >=20 > =46rom section 4.4 Map-Resolver Processing: > To minimize the number of negative cache entries needed by an ITR, the > Map-Resolver should return the least-specific prefix which both > matches the original query and does not match any EID-prefix known to > exist in the LISP-capable infrastructure. >=20 > This is a good approach in most circumstances, where there are few > packets to unknown destinations (few "punts" to the control-plane.) > It breaks down, however, in the event the ITR needs to process a large > amount of packets to unknown destinations, such as: > * a deliberate DoS attack on the ITR from within > * reply packets to an external DoS attack with false, random source = addresses > * a malicious worm searching for hosts to infect > * etc. >=20 > All of the above contribute to FIB churn. They may also cause a large > number of negative mapping cache entries to be populated on the ITR. > To demonstrate how the mechanism in draft-ietf-lisp-ms-07 is not ideal > in this situation, all you must do is emulate the existing IPv6 > routing table, which contains numerous, costly-to-express holes. For > example, current ARIN IPv6 allocations to ISPs are /32 in size but are > aligned on /23 boundaries. These holes between "adjacent" (minus > holes) /32 ISP allocations allow a malicious person to cause an ITR to > learn nine (9) negative mapping cache entries between each two /32 > allocations, if one was utilizing LISP on Internet-scale, and LISP > were widely-deployed. >=20 Can you provide real numbers instead of just example? Have you ever = counted the holes? Isn't possible to avoid this by filtering? The ITR can avoid sending any = request for IPv6 unallocated space.=20 Luigi > The draft language does not leave room for alternatives, but it > probably should. A different mechanism works better in this > situation, allowing the ITR to learn about all feasible prefix > mappings within a given supernet. This may allow the ITR to reduce > its number of negative cache entries dramatically by installing a far > smaller number of positive mappings (to control-plane cache for > possible use, or to FIB.) >=20 > This is of more importance than is immediately obvious, because one > must consider the cost of "punts" to the control-plane in order to > drive the learning process. These punts must be policed somehow, and > surely, they will be by vendor implementations with a "hardware FIB" > and a "software negative cache." However, when faced with a large > volume of punts (packets to unknown destinations, causing a negative > cache hit or a new Mapping Service inquiry), an implementation might > choose to actually install negative mappings into his FIB, preventing > these known-bad punts from reaching the control-plane *and* preventing > them from contenting for policer conformance with other punts which > are needed to learn new mappings for legitimate traffic. This means > the cost of pushing some negative cache entries into the FIB should be > considered, and the cost of doing so should be able to be minimized by > the implementation. >=20 > I suggest the Mapping Service specification leave room for an ITR that > wishes to request all mappings within a given subset of the feasible > routing table. This gives the implementor additional options for > dealing with malicious traffic which may drive its negative mapping > cache to a large size, and perhaps consume precious FIB resources as > well. >=20 > Darrel Lewis tells me there was a similar capability in a router with > "on-demand FIB compression." While the application differs in this > case, the principle is the same. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From internet-drafts@ietf.org Mon Jul 11 03:26:37 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1221F8AF5; Mon, 11 Jul 2011 03:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zciFjmqRcyVC; Mon, 11 Jul 2011 03:26:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9A21F8ACE; Mon, 11 Jul 2011 03:26:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711102637.3235.17129.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 03:26:37 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:26:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-01.txt Pages : 22 Date : 2011-07-11 This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt From ljakab@ac.upc.edu Mon Jul 11 03:36:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0821F8AEA for ; Mon, 11 Jul 2011 03:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYR77gf50eI7 for ; Mon, 11 Jul 2011 03:36:31 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0591E21F89FA for ; Mon, 11 Jul 2011 03:36:30 -0700 (PDT) Received: from [147.83.34.118] (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id EA0E22D0002; Mon, 11 Jul 2011 12:36:28 +0200 (CEST) Message-ID: <4E1AD225.9090605@ac.upc.edu> Date: Mon, 11 Jul 2011 12:36:21 +0200 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: <20110711102637.3235.17129.idtracker@ietfa.amsl.com> In-Reply-To: <20110711102637.3235.17129.idtracker@ietfa.amsl.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:36:31 -0000 Folks, We moved the PITR scenarios to a new section discussing coexistence/migration/transition, and evolved the Tier 1 scenario into a much better PITR route distribution architecture, that will be presented in Quebec. Regards, Lorand Jakab (on behalf of the draft authors) On 07/11/11 12:26, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. > > Title : LISP Network Element Deployment Considerations > Author(s) : Lorand Jakab > Albert Cabellos-Aparicio > Florin Coras > Jordi Domingo-Pascual > Darrel Lewis > Filename : draft-ietf-lisp-deployment-01.txt > Pages : 22 > Date : 2011-07-11 > > This document discusses the different scenarios for the deployment of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-01.txt > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jsw@inconcepts.biz Mon Jul 11 12:25:28 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C436011E8171 for ; Mon, 11 Jul 2011 12:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj0QPCjKFZGR for ; Mon, 11 Jul 2011 12:25:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 114A611E816F for ; Mon, 11 Jul 2011 12:25:27 -0700 (PDT) Received: by vws12 with SMTP id 12so4383824vws.31 for ; Mon, 11 Jul 2011 12:25:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.163 with SMTP id m3mr6103336vdv.244.1310412327289; Mon, 11 Jul 2011 12:25:27 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Mon, 11 Jul 2011 12:25:27 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <59EFA289-F796-4803-B95E-39FBB12E270B@net.t-labs.tu-berlin.de> References: <59EFA289-F796-4803-B95E-39FBB12E270B@net.t-labs.tu-berlin.de> Date: Mon, 11 Jul 2011 15:25:27 -0400 Message-ID: From: Jeff Wheeler To: Luigi Iannone Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 19:25:28 -0000 On Mon, Jul 11, 2011 at 6:01 AM, Luigi Iannone wrote: > Can you provide real numbers instead of just example? Have you ever count= ed the holes? Luigi, the holes in the IPv6 space are there due to RIR allocation strategy. If I am an ISP and request a /32 for my customers, they will give me a /32 aligned to a /23 boundary, and not allocate any other blocks out of that /23 (at least not yet) in case I need to grow my address space. This is what produces the holes that are guaranteed to allow attacking the vulnerable negative mapping cache, if LISP were widely-deployed on the Internet. So you can see that it is not just a hypothetical "what if the address space had lots of holes..." problem, but a practical "there are lots of holes and LISP will perform badly due to this as it scales up." > Isn't possible to avoid this by filtering? The ITR can avoid sending any = request for IPv6 unallocated space. You must understand how routers work to see why this is possible, but requires 10x more FIB space than the number of possible positive mapping entries (for the case of IPv6, given current allocation strategy.) How does the ITR learn about a mapping for a newly-arrived packet/flow? Packets bound for a yet-unknown destination must be punted from the data-plane to the control-plane, where the router's CPU can check its potentially larger mapping cache (if control-plane cache is larger than FIB.) This punting is itself the problem. In order to filter punts for unallocated space, you must install something into the data-plane / FIB to match them -- this means you can either install all positive mappings, or you can load negative mappings on-demand, or you can not filter them at all and punt garbage look-ups to the CPU. There is no easy way to "avoid sending any request for unallocated space" at a granular level that would protect the CPU in an Internet-scale LISP deployment. Simply increasing the size of the control-plane cache, and not turning the punts into MS queries, is not enough. The MS will be able to service a very high rate of requests and is fairly easy and inexpensive to scale up. The problem is the router CPU cannot receive an infinite number of punts before failing, and the data-plane cannot churn its FIB at an infinite rate either. On modern routers, the limit of these functions is on the order of 20,000 punts or FIB updates per second. This is why it would be trivial to disable an ITR, because the filtering you suggest is not possible without a huge FIB, defeating the purpose of using a cache at all. I believe the only way for LISP to scale up in a dense, mixed-use data-center environment, where the hosts may be untrustworthy, is for the hosts themselves to be their own ITR. However, modifying the mapping service spec to allow for a different way of handling negative responses can significantly improve the situation, to the point where the ITR only needs enough FIB to hold approximately the whole possible routing table, not 10x more entries due to negative "filter" entries as you suggest. If you do not consider how the ITR actually works, and this seems to be the case with a lot of the work on LISP today, it is easy to focus your efforts on interactions within the LISP signalling infrastructure without ever realizing that the data-plane has vulnerabilities. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From luigi@net.t-labs.tu-berlin.de Tue Jul 12 00:45:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A0C21F90D4 for ; Tue, 12 Jul 2011 00:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDEnYZYDdH4E for ; Tue, 12 Jul 2011 00:45:03 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 276BB21F90D2 for ; Tue, 12 Jul 2011 00:45:03 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 140AD70B3882; Tue, 12 Jul 2011 09:45:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Tue, 12 Jul 2011 09:45:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59EFA289-F796-4803-B95E-39FBB12E270B@net.t-labs.tu-berlin.de> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:45:04 -0000 Jeff, what you are describing is nothing new and is not limited to LISP. Hence = I do not understand the alarmist tone of your emails. If you want to propose text describing the issue for the next version of = the threats draft, I will be happy to include it. (please do not include = any solution since it is not the place to document it. Please be = concise.) Thanks Luigi On Jul 11, 2011, at 21:25 , Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 6:01 AM, Luigi Iannone > wrote: >> Can you provide real numbers instead of just example? Have you ever = counted the holes? >=20 > Luigi, the holes in the IPv6 space are there due to RIR allocation > strategy. If I am an ISP and request a /32 for my customers, they > will give me a /32 aligned to a /23 boundary, and not allocate any > other blocks out of that /23 (at least not yet) in case I need to grow > my address space. This is what produces the holes that are guaranteed > to allow attacking the vulnerable negative mapping cache, if LISP were > widely-deployed on the Internet. So you can see that it is not just a > hypothetical "what if the address space had lots of holes..." problem, > but a practical "there are lots of holes and LISP will perform badly > due to this as it scales up." >=20 >> Isn't possible to avoid this by filtering? The ITR can avoid sending = any request for IPv6 unallocated space. >=20 > You must understand how routers work to see why this is possible, but > requires 10x more FIB space than the number of possible positive > mapping entries (for the case of IPv6, given current allocation > strategy.) >=20 > How does the ITR learn about a mapping for a newly-arrived > packet/flow? Packets bound for a yet-unknown destination must be > punted from the data-plane to the control-plane, where the router's > CPU can check its potentially larger mapping cache (if control-plane > cache is larger than FIB.) This punting is itself the problem. In > order to filter punts for unallocated space, you must install > something into the data-plane / FIB to match them -- this means you > can either install all positive mappings, or you can load negative > mappings on-demand, or you can not filter them at all and punt garbage > look-ups to the CPU. >=20 > There is no easy way to "avoid sending any request for unallocated > space" at a granular level that would protect the CPU in an > Internet-scale LISP deployment. Simply increasing the size of the > control-plane cache, and not turning the punts into MS queries, is not > enough. The MS will be able to service a very high rate of requests > and is fairly easy and inexpensive to scale up. The problem is the > router CPU cannot receive an infinite number of punts before failing, > and the data-plane cannot churn its FIB at an infinite rate either. > On modern routers, the limit of these functions is on the order of > 20,000 punts or FIB updates per second. >=20 > This is why it would be trivial to disable an ITR, because the > filtering you suggest is not possible without a huge FIB, defeating > the purpose of using a cache at all. >=20 > I believe the only way for LISP to scale up in a dense, mixed-use > data-center environment, where the hosts may be untrustworthy, is for > the hosts themselves to be their own ITR. However, modifying the > mapping service spec to allow for a different way of handling negative > responses can significantly improve the situation, to the point where > the ITR only needs enough FIB to hold approximately the whole possible > routing table, not 10x more entries due to negative "filter" entries > as you suggest. >=20 > If you do not consider how the ITR actually works, and this seems to > be the case with a lot of the work on LISP today, it is easy to focus > your efforts on interactions within the LISP signalling infrastructure > without ever realizing that the data-plane has vulnerabilities. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From damien.saucez@uclouvain.be Tue Jul 12 01:07:23 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334621F8EF0 for ; Tue, 12 Jul 2011 01:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS3tBndRPQ5E for ; Tue, 12 Jul 2011 01:07:22 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2E97121F9040 for ; Tue, 12 Jul 2011 01:07:22 -0700 (PDT) Received: from [IPv6:2001:6a8:3080:2:226:b0ff:feea:17c0] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 338FF11E405; Tue, 12 Jul 2011 10:06:48 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 338FF11E405 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310458008; bh=5tDrf9l5jPNt7aJBfjcXqQMvRObsqmnVqnK5tzJlHec=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=X2GgOkFMbuV9g6f0m+PDMleHOqw2PCUF1SdY7Z7Mq8svnCzDra2B7Ly40AC7+Apnv uIXWY44CtXgJmiCdsL3QysdrPNaMKtIyOvluZsFmItGiSQv3ov25ItCFGPUt6bovIJ Bwca2jdoI8yVycyYLDcLxAR7LWW52panFPqlKYrE= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Tue, 12 Jul 2011 10:06:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 338FF11E405.A14E2 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 08:07:23 -0000 Hello Jeff, Again thank you for your interest in LISP and please be sure that we are = considering your comments as they merit to be. In our discussion last week, I proposed to add a discussion about the = risk of cache poisoning with negative replies. The draft with this discussion will be submitted = with the other comments that we will receive during the next IETF. So that, the draft should be = presented publicly available during mid of August. Otherwise, feel free to participate in the effort = for securing the mappings (see draft-saucez-lisp-mapping-security-00) where we are looking to see how = to avoid someone to cheat with the mappings it provides. However, in our mail exchanges, I said that the cache management was = more than a security problem and was more important than just negative replies. You can inject a lot = of entries with positive replies as well, particularly in IPv6. You can have this by massively de = aggregating the prefixes. Again, this is not a security problem, this feature can lead to security but cache = management is first a general problem in LISP and in Map-and-Encap in general. It thus merit to be discussed = in the main specs. However,=20 researches have shown that the cache management was not as dramatic as = we could expect. Of course the first study in 2007 was with a mid-size campus network and I could = understand that you considered that the work was not relevant. Nevertheless, the study has been = repeated this year with a traffic trace from an operator (and not a pet-operator, a real one that has millions of = customer today) and the conclusion is the same. So if you still think that our research sucks and is not = representative, I would be very happy to get a traffic trace on your network and do the evaluation. The only limit we = have is the time you are ready to wait for the simulation to complete! Do not hesitate to provide us a 10-year = full packet trace from your network and we will do all the work for you to see if LISP could be used in your = network or if it would become a catastrophe.=20 On 11 Jul 2011, at 06:57, Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 12:29 AM, Dino Farinacci = wrote: >> I don't know what you mean, but if your definition of a 'destination >> network' is either a single or multi-homed site, then the FIB would = hold 50K >> entries. >=20 > I am not responding to all of the points raised in your message, > because you are still missing the fundamental problem that negative > replies from the LISP Mapping Service, which should be cached in the > ITR, can cause the table to be inflated to a size that is, literally, > ten times the number of possible positive mapping entries. Once > again, read my original LISP mailing list post on this subject. >=20 As I am mentioning since a few days now, your are focusing on a small = part of the problem. The real problem is cache management in general. Negative replies are only a = very very small part of the problem. > If you read the part in the MS draft that dictates negative replies > must not overlap any possible positive mappings, and consider how RIRs > are currently allocating IPv6 address space to networks, you should > easily realize how this part of the MS protocol needs additional > flexibility. Quite simply, a 50k entry IPv6 table would indeed > consume 500k entries when negative entries are included. >=20 Could you provide more information about the numbers? =46rom where is = the 10 factor coming? > The simple arithmetic is in my original post, months ago. >=20 I think that the problem is more than just simple arithmetic so please = provide more details about how you obtained your results. Sorry I am just a researcher so I do need = a lot of details to be able to understand the things. Thank you again and please ask for a slot at next IETF to make the = discussion growing. Cheers, Damien Saucez > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jsw@inconcepts.biz Tue Jul 12 01:45:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416E21F903D for ; Tue, 12 Jul 2011 01:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwG04C-sd4B4 for ; Tue, 12 Jul 2011 01:45:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F09821F903B for ; Tue, 12 Jul 2011 01:45:57 -0700 (PDT) Received: by vws12 with SMTP id 12so4919936vws.31 for ; Tue, 12 Jul 2011 01:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.197 with SMTP id g5mr1692733vcx.254.1310460355947; Tue, 12 Jul 2011 01:45:55 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Tue, 12 Jul 2011 01:45:55 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> Date: Tue, 12 Jul 2011 04:45:55 -0400 Message-ID: From: Jeff Wheeler To: Damien Saucez Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 08:45:58 -0000 On Tue, Jul 12, 2011 at 4:06 AM, Damien Saucez wrote: > However, in our mail exchanges, I said that the cache management was more= than a security problem > and was more important than just negative replies. You can inject a lot o= f entries with positive replies as > well, particularly in IPv6. You can have this by massively de aggregating= the prefixes. Again, this is As I have mentioned, a malicious person does not need access to any LISP infrastructure. They will not need to inject new prefixes. All an attacker must do is send packets in a systemic manner to exploit the way LISP MS negative replies work -- by sending back non-overlapping negative responses, which may be more numerous than the possible number of positive mappings (especially for IPv6.) >> flexibility. =A0Quite simply, a 50k entry IPv6 table would indeed >> consume 500k entries when negative entries are included. > > Could you provide more information about the numbers? From where is the 1= 0 factor coming? Again, you must read my original post on this subject. An example may be helpful. Imagine I wish to attack your ITR, which can learn about two routes, fc00:9000::/32 and fc00:9200::/32. There is a large hole between these two routes, due to RIR allocation strategy. In order to use up more MS cache entries on your ITR, I can send one packet each within the following prefixes, all of which will cause an MS query, negative response, and use up resources in the ITR: fc00:9001::/32 fc00:9002::/31 fc00:9004::/30 fc00:9008::/29 fc00:9010::/28 fc00:9020::/27 fc00:9040::/26 fc00:9080::/25 fc00:9100::/24 So you can see that there are two (2) positive mapping entries and nine (9) negative entries. Now add a third positive mapping at fc00:9400::/32 and you gain another nine negative entries. That continues to be the case for every possible /32 allocation aligned on a /23 boundary, thus producing a hole which requires nine VLSM list entries to be represented. If you have 50k positive mappings in the system, you will have 450k negatives making up those holes, requiring a 500k entry state database on the ITR to avoid churn. Obviously the goal of such a DoS will be to exploit either bad behavior during excess churning, cripple the CPU due to excess punts, or use up all the cache so the correct ETR destination for legitimate traffic can't be learned. The reason for this is the Mapping Server is not allowed to send a negative response which overlaps a possible positive response. The hole can't be aggregated into "hole + one longer positive" even though this would be easy for the router to understand, and indeed, to install into FIB if necessary (to guard the CPU against punts.) There will most likely be 50k actual IPv6 destination prefixes within a few years, if each ASN active today receives about one IPv6 allocation. If LISP were implemented widely on the Internet, it would know about 50k mappings and be subject to learning about 450k holes when abused. This means the affect of caching is actually that a bigger FIB is required when the router is subjected to this attack, than if it wasn't able to cache at all, and simply learned all routes from the mapping system. If an ETR wants to be able to verify that ingress traffic is coming from a legitimate ITR for the source, I believe ETRs will also have a scaling problem here, which I think will be easier to exploit than the ITR. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From darlewis@cisco.com Tue Jul 12 05:57:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA021F8F0A for ; Tue, 12 Jul 2011 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.146 X-Spam-Level: X-Spam-Status: No, score=-5.146 tagged_above=-999 required=5 tests=[AWL=-2.546, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIBNry8o2mjK for ; Tue, 12 Jul 2011 05:57:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 15CC521F8F06 for ; Tue, 12 Jul 2011 05:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=1108; q=dns/txt; s=iport; t=1310475420; x=1311685020; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=teMOSNFkTbe5fo+fCle6N5RfSRqYB9hWOiH6t7q973U=; b=P/wqxvgkfPpgro3PXJ4N73hIMpz3mV3Kc8zB+k0i8d4ZPm2DjgxKXo+l QdmHbNJCLCvIXGQq/vfBVCfk6C6KPTc1qnI3CRcniYTrim8lDMUvcJ/H6 f6+TcYyd5IfjasQlTXmOyC5JJJsf7ENW7AmpM6UY2NWAxXNtRm/IhZd9b o=; X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="2107721" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2011 12:56:59 +0000 Received: from sjc-vpn4-962.cisco.com (sjc-vpn4-962.cisco.com [10.21.83.193]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6CCuwX7000763; Tue, 12 Jul 2011 12:56:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: Date: Tue, 12 Jul 2011 05:56:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 12:57:01 -0000 On Jul 12, 2011, at 1:45 AM, Jeff Wheeler wrote: > On Tue, Jul 12, 2011 at 4:06 AM, Damien Saucez > wrote: >> However, in our mail exchanges, I said that the cache management was = more than a security problem >> and was more important than just negative replies. You can inject a = lot of entries with positive replies as >> well, particularly in IPv6. You can have this by massively de = aggregating the prefixes. Again, this is >=20 > As I have mentioned, a malicious person does not need access to any > LISP infrastructure. They will not need to inject new prefixes. All > an attacker must do is send packets in a systemic manner to exploit > the way LISP MS negative replies work -- by sending back > non-overlapping negative responses, Just so I can understand, are you saying that the attack may send = unsolicited Map-Replies to an ITR? Or are you suggesting you send, say, a syn packet with a spoofed source = to a host within the site, expecting the resultant syn-ack to result in = a map-request sent into the mapping system? -Darrel From jsw@inconcepts.biz Tue Jul 12 10:42:27 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68921F8D39 for ; Tue, 12 Jul 2011 10:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA8PFJgdAHKI for ; Tue, 12 Jul 2011 10:42:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2121F8D38 for ; Tue, 12 Jul 2011 10:42:26 -0700 (PDT) Received: by vws12 with SMTP id 12so5403809vws.31 for ; Tue, 12 Jul 2011 10:42:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.161 with SMTP id dh1mr268703vdc.177.1310492545783; Tue, 12 Jul 2011 10:42:25 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Tue, 12 Jul 2011 10:42:25 -0700 (PDT) X-Originating-IP: [96.28.66.189] In-Reply-To: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> Date: Tue, 12 Jul 2011 13:42:25 -0400 Message-ID: From: Jeff Wheeler To: Darrel Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 17:42:27 -0000 On Tue, Jul 12, 2011 at 8:56 AM, Darrel Lewis wrote: > Just so I can understand, are you saying that the attack may send unsolic= ited Map-Replies to an ITR? > > Or are you suggesting you send, say, a syn packet with a spoofed source t= o a host within the site, expecting the resultant syn-ack to result in a ma= p-request sent into the mapping system? I suggest the second case. I assume here that the LISP MS infrastructure itself is not accessible to a malicious attacker. Whatever way the "bad packets" reach a host downstream of an ITR, if they generate responses (SYN|ACK, etc.) then the ITR must try to forward them. Like you said above, if the ITR doesn't know what to do with these packets, it is going to try to learn how by punting to the CPU, initiating a MS query, and so on. You might say that if LISP can be further developed and deployed, in an ideal world, there might not be any spoofed traffic. This would be nice, except if a LISP ETR has to do a similar look-up when bringing traffic into the network subject to attack, then the ETR may also suffer from essentially the same problem as the ITR. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From rcallon@juniper.net Wed Jul 13 19:58:38 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501E511E80E2 for ; Wed, 13 Jul 2011 19:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y1CH6BdYsKF for ; Wed, 13 Jul 2011 19:58:38 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD5611E8092 for ; Wed, 13 Jul 2011 19:58:29 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTh5bVINaqDZabYnmnx6sJChJmu2QVR2O@postini.com; Wed, 13 Jul 2011 19:58:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 19:55:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 13 Jul 2011 22:55:54 -0400 From: Ross Callon To: Damien Saucez Date: Wed, 13 Jul 2011 22:55:51 -0400 Thread-Topic: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxAar1tND75VEUkSXmz0uXQyLL1FwBZTi2w Message-ID: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> In-Reply-To: <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 02:58:38 -0000 A comment on one particular point from your email... > ... However,=20 > researches have shown that the cache management was not as dramatic as we= could expect. Of course > the first study in 2007 was with a mid-size campus network and I could un= derstand that you considered > that the work was not relevant. Nevertheless, the study has been repeated= this year with a traffic trace from > an operator (and not a pet-operator, a real one that has millions of cust= omer today) and the conclusion is > the same.=20 I have read a couple of papers on this issue, which I believe are probably = the ones that you are referring to. The papers that I read both assume that= the granularity of the EID-to-RLOC tables will be the same as the granular= ity of the current top level BGP routing table. If this assumption is wrong= , then the results will be correspondingly inaccurate.=20 To me it seems highly unlikely that this assumption is within an order of m= agnitude of being correct.=20 Ross From lear@cisco.com Wed Jul 13 22:41:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3221F8C09 for ; Wed, 13 Jul 2011 22:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmqc4OTeWk6W for ; Wed, 13 Jul 2011 22:41:22 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0087A21F8C01 for ; Wed, 13 Jul 2011 22:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1664; q=dns/txt; s=iport; t=1310622082; x=1311831682; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k0Uy7P/Rp47+ENdF+cBgCOUS9r4iZ7OFOR3Aq/mauu0=; b=MsulaClaUcUQKlsqJbuF6eDt1DJ17qPGo7TfLHJqWt1kxnvjAC9Z3Dz+ 9qLrs6IRPvop6O/wTKRGhePGUbd3UkNienB92dKtS9z+PrgrY/thHuZMe TDXb1YUm6anTrjsSkmM83tn8ojQd5fL9kcAcLeRhGynZCCVZ1ZYCL1mul Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKCAHk6Q/khM/2dsb2JhbABThEajC3esHI0dkQOBK4QAgQ8EkmSQUg X-IronPort-AV: E=Sophos;i="4.65,527,1304294400"; d="scan'208";a="101986728" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2011 05:41:21 +0000 Received: from dhcp-10-55-89-119.cisco.com (dhcp-10-55-89-119.cisco.com [10.55.89.119]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6E5fKk6012417; Thu, 14 Jul 2011 05:41:20 GMT Message-ID: <4E1E8181.8070709@cisco.com> Date: Thu, 14 Jul 2011 07:41:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ross Callon References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 05:41:26 -0000 Ross, On 7/14/11 4:55 AM, Ross Callon wrote: > I have read a couple of papers on this issue, which I believe are probably the ones that you are referring to. The papers that I read both assume that the granularity of the EID-to-RLOC tables will be the same as the granularity of the current top level BGP routing table. If this assumption is wrong, then the results will be correspondingly inaccurate. > > To me it seems highly unlikely that this assumption is within an order of magnitude of being correct. There are now two discussions intermixed in this thread: 1. What is the projected cache growth rate based on legitimate use? 2. What are the security considerations regarding cache attacks. In the first instance, let me suggest that the whole point of LISP is to disentangle memory consumption from number of reachable points on the Internet, but rather bound it to the number of sites actually being reached. That is what induces the concern that Jeff has raised with the 2nd discussion. What Jeff has described is a variation of the classic reflection attack. This is, IMHO, probably worth noting more explicitly, as an area for future work. I do not agree with Jeff that the only approach to solving this problem is to allow for overlapping negative / positive responses. That itself can cause other problems. For instance, it causes confusion as to when in fact a query must be sent if a negative entry is already cached, but there exists a positive entry somewhere in the world. In any case, I suggest we add a line that states the risk but not attempt to solve it in this round of the experiment. Eliot From damien.saucez@uclouvain.be Thu Jul 14 00:07:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43F221F8B91 for ; Thu, 14 Jul 2011 00:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meRROpmVm9GD for ; Thu, 14 Jul 2011 00:07:06 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5F21F8797 for ; Thu, 14 Jul 2011 00:07:06 -0700 (PDT) Received: from [IPv6:2001:6a8:3080:2:226:b0ff:feea:17c0] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5FEB71C5444; Thu, 14 Jul 2011 09:07:01 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 5FEB71C5444 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310627221; bh=A5KlOZx6dMlFVmQsZlNmSz+gNaYV4LF+l548uBYFX1g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZYfMLPO7LJUtSLPKoVRD46eN644D+7prKb+BaLTaycFxDyblpIazvsEwACorW6M+A 0s8b8N2YsxROWHxG6jpWQaWFueD5uwuWKmg6q1bTQX92hCO3Z8B3+KHeHfLyusUhsP HoEM8oDKNtb8q5I++qy/Jh0DHgJ0Fj7EuRLJidLw= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Thu, 14 Jul 2011 07:20:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96FBD7BD-56B3-425F-A294-88A8CD649382@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5FEB71C5444.A2470 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:07:11 -0000 Hello Jeff, I thought about the problem and think that there is deployment solution = that could correct the problem. Here I am supposing that the mappings are secured (which is a must for me as u can see from my drafts). Of course = it would work without secure mapping but then it would be dangerous (see LISP-SEC Fabio's draft). Currently, when a map-request is sent, you receive the mapping for the longest-match prefix corresponding. So why not changing to receive a Map-Reply that contains as today the reply to the request + the a negative-mapping with the longest-match prefix of the RIR that contains this. The RIR knows how it assigns the prefixes, so it is easy to = provide this. In your example, you just have to send fc00:9000::/32 positive mappings and the corresponding negative /23 with a TTL lasting the time the RIR is subject to assign a new sub-prefix of this /23. There is plenty = of solutions to ensure this mechanism (MS bases, mapping system bases, ETR based), I will not propose them here, but I am open to start a draft with you that present the issue and the solution. Or you can ask for a slot @IETF81 to present the problem and I would also ask for a slot with the solution. Thank you, Damien Saucez On 12 Jul 2011, at 10:45, Jeff Wheeler wrote: > On Tue, Jul 12, 2011 at 4:06 AM, Damien Saucez > wrote: >> However, in our mail exchanges, I said that the cache management was = more than a security problem >> and was more important than just negative replies. You can inject a = lot of entries with positive replies as >> well, particularly in IPv6. You can have this by massively de = aggregating the prefixes. Again, this is >=20 > As I have mentioned, a malicious person does not need access to any > LISP infrastructure. They will not need to inject new prefixes. All > an attacker must do is send packets in a systemic manner to exploit > the way LISP MS negative replies work -- by sending back > non-overlapping negative responses, which may be more numerous than > the possible number of positive mappings (especially for IPv6.) >=20 >>> flexibility. Quite simply, a 50k entry IPv6 table would indeed >>> consume 500k entries when negative entries are included. >>=20 >> Could you provide more information about the numbers? =46rom where is = the 10 factor coming? >=20 > Again, you must read my original post on this subject. An example may > be helpful. Imagine I wish to attack your ITR, which can learn about > two routes, fc00:9000::/32 and fc00:9200::/32. There is a large hole > between these two routes, due to RIR allocation strategy. In order to > use up more MS cache entries on your ITR, I can send one packet each > within the following prefixes, all of which will cause an MS query, > negative response, and use up resources in the ITR: > fc00:9001::/32 > fc00:9002::/31 > fc00:9004::/30 > fc00:9008::/29 > fc00:9010::/28 > fc00:9020::/27 > fc00:9040::/26 > fc00:9080::/25 > fc00:9100::/24 > So you can see that there are two (2) positive mapping entries and > nine (9) negative entries. Now add a third positive mapping at > fc00:9400::/32 and you gain another nine negative entries. That > continues to be the case for every possible /32 allocation aligned on > a /23 boundary, thus producing a hole which requires nine VLSM list > entries to be represented. >=20 > If you have 50k positive mappings in the system, you will have 450k > negatives making up those holes, requiring a 500k entry state database > on the ITR to avoid churn. Obviously the goal of such a DoS will be > to exploit either bad behavior during excess churning, cripple the CPU > due to excess punts, or use up all the cache so the correct ETR > destination for legitimate traffic can't be learned. >=20 > The reason for this is the Mapping Server is not allowed to send a > negative response which overlaps a possible positive response. The > hole can't be aggregated into "hole + one longer positive" even though > this would be easy for the router to understand, and indeed, to > install into FIB if necessary (to guard the CPU against punts.) >=20 > There will most likely be 50k actual IPv6 destination prefixes within > a few years, if each ASN active today receives about one IPv6 > allocation. If LISP were implemented widely on the Internet, it would > know about 50k mappings and be subject to learning about 450k holes > when abused. This means the affect of caching is actually that a > bigger FIB is required when the router is subjected to this attack, > than if it wasn't able to cache at all, and simply learned all routes > from the mapping system. >=20 > If an ETR wants to be able to verify that ingress traffic is coming > from a legitimate ITR for the source, I believe ETRs will also have a > scaling problem here, which I think will be easier to exploit than the > ITR. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts From damien.saucez@uclouvain.be Thu Jul 14 00:32:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6721F88CE for ; Thu, 14 Jul 2011 00:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WzeIePYkW1W for ; Thu, 14 Jul 2011 00:32:25 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB1721F88B6 for ; Thu, 14 Jul 2011 00:32:25 -0700 (PDT) Received: from [IPv6:2001:6a8:3080:2:226:b0ff:feea:17c0] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0B7DA1C547A; Thu, 14 Jul 2011 09:32:22 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 0B7DA1C547A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310628742; bh=QbFvuWMzr2F1/ui13xMI2XlBBkpy9NpqOjhiz+kW2sc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TxyPtTVo+cSIOdTUGGzUdCLhWIjSzLZNFflLR4lXdJ4hacDT6s9bIkCnCWO5Ss1jq YVlYPaGMEv9px2Z+con43xgD9ct0b66M/L2RWd7zRRE40JQcJ7y/fZUGO6lmlECRYj Qia53N1EcnFJ0/8MSWEuHobIoPGdg+y0ALqR/Dv4= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4E1E8181.8070709@cisco.com> Date: Thu, 14 Jul 2011 09:32:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7AF3895A-DAED-4B5E-81BE-C0B14A0F3161@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <4E1E8181.8070709@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 0B7DA1C547A.A549E X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:32:30 -0000 Eliot, On 14 Jul 2011, at 07:41, Eliot Lear wrote: > Ross, >=20 > On 7/14/11 4:55 AM, Ross Callon wrote: >> I have read a couple of papers on this issue, which I believe are = probably the ones that you are referring to. The papers that I read both = assume that the granularity of the EID-to-RLOC tables will be the same = as the granularity of the current top level BGP routing table. If this = assumption is wrong, then the results will be correspondingly = inaccurate.=20 >>=20 >> To me it seems highly unlikely that this assumption is within an = order of magnitude of being correct.=20 >=20 > There are now two discussions intermixed in this thread: >=20 > 1. What is the projected cache growth rate based on legitimate use? >=20 > 2. What are the security considerations regarding cache attacks. >=20 > In the first instance, let me suggest that the whole point of LISP is = to > disentangle memory consumption from number of reachable points on the > Internet, but rather bound it to the number of sites actually being > reached. That is what induces the concern that Jeff has raised with = the > 2nd discussion. What Jeff has described is a variation of the classic > reflection attack. This is, IMHO, probably worth noting more > explicitly, as an area for future work. >=20 > I do not agree with Jeff that the only approach to solving this = problem > is to allow for overlapping negative / positive responses. That = itself > can cause other problems. For instance, it causes confusion as to = when > in fact a query must be sent if a negative entry is already cached, = but > there exists a positive entry somewhere in the world. In any case, I > suggest we add a line that states the risk but not attempt to solve it > in this round of the experiment. You are right but I think this problem can be solved with the ACT bit = with the value 0x02 and overlapping mappings. Indeed, the assigned prefixes are known for sure and the "holes" do not change too frequently. So the = result of a request in a hole could be the large "holed" prefix with a TTL that = corresponds to the time before which no hole will be assigned (depends on the policy = of prefix assignments but I think it should be not less than one day), this is a = negative reply with the ACT bits =3D 0x0. And all the aggregated prefixes that have = been assigned in this prefix in a negative reply form with the ACT bit =3D = 0x2 meaning that the ITR must send a map-request before trying to encapsulate the packets = in such sub-prefixes. For example, if you have 192.0.2.0/24 and only 192.0.2.0/30 and = 192.0.2.128/30 that are assigned, the reply for let say 192.0.2.13 could be 192.0.2.0/24, negative, ACT=3D0x0, TTL=3D 1day 192.0.2.0/30, negative, ACT=3D0x2, TTL=3Dmin lease time 192.0.2.128/30, negative, ACT=3D0x2, TTL=3Dmin lease time where min lease time is the minimum time a prefix in the aggregate of = sub-prefix is assigned to the company. For example, if the prefix 192.0.2.0/30 is = assigned on a year basis, its TTL can safely be 1 year as it has the ACT=3D0x2 = meaning that the ITR will request for mappings corresponding to addresses in this prefix = on demand. Damien Saucez >=20 > Eliot From damien.saucez@uclouvain.be Thu Jul 14 01:03:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6721F8B2B for ; Thu, 14 Jul 2011 01:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPWoDncS0cig for ; Thu, 14 Jul 2011 01:03:50 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 64D7221F8B27 for ; Thu, 14 Jul 2011 01:03:50 -0700 (PDT) Received: from [IPv6:2001:6a8:3080:2:226:b0ff:feea:17c0] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1793B1C54C2; Thu, 14 Jul 2011 10:03:46 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 1793B1C54C2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310630626; bh=4JLYpKf6NfwZf8WqpAhtp06WaHlerVK5a8jYp3gHS0g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=enNKh0Si8Bp/eKoZt/BYj7fRA4ptrpkEO/lu9RAI1bWp3u/vJYIGS2VR0YYntHlUS ui5v22Cbez5OZ79sgK8Xb5fviCnYDEYEt1z/bRKUBFMAVg84gyfc3Kd4Pb6pgM5ThE swpPKPUAYUNGjAsgEkPQ599aBsJP0+gZeGZBmMks= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Thu, 14 Jul 2011 10:03:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> To: Ross Callon X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1793B1C54C2.A1EE1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 08:03:55 -0000 Ross, On 14 Jul 2011, at 04:55, Ross Callon wrote: > A comment on one particular point from your email... >=20 >> ... However,=20 >> researches have shown that the cache management was not as dramatic = as we could expect. Of course >> the first study in 2007 was with a mid-size campus network and I = could understand that you considered >> that the work was not relevant. Nevertheless, the study has been = repeated this year with a traffic trace from >> an operator (and not a pet-operator, a real one that has millions of = customer today) and the conclusion is >> the same.=20 >=20 > I have read a couple of papers on this issue, which I believe are = probably the ones that you are referring to. The papers that I read both = assume that the granularity of the EID-to-RLOC tables will be the same = as the granularity of the current top level BGP routing table. If this = assumption is wrong, then the results will be correspondingly = inaccurate.=20 >=20 > To me it seems highly unlikely that this assumption is within an order = of magnitude of being correct.=20 At a first glance, the assumption might look bad, but I believe it is = not the case. Indeed, the evaluation are made with real BGP feeds to determine the number of prefixes. However, this = morning I look my FIB and saw 52% of /24, the rest being less specific than that. So know imagine that the whole = Internet become de-agregated, it means that we would have 100% of /24 thus in the very worst case, we would double = the number of required entries which remains acceptable. Would you allow prefixes more specific than /24 in = EID? In addition, many of the prefixes we are seeing on the Internet are just there because of the incoming TE = limitations of BGP (e..g, de-agregation, aspath pre-pending, blah blah) but with mappings you do not need these = artifacts and because you have the list of locators and the weight you can even do less specific than /24 = with the same result (with better end-to-end control) and at the end one can expect to have the mapping churn lower = than the current BGP churn. Another point in favor of this decomposition is that people would = probably not be happy to renumber their network and then simply migrate their PI addresses into EIDs. Thus, the current = prefix would appear as LISP EID prefixes. So all-in-all, the numbers obtained in the different papers are not so = dumb if we assume that LISP is deployed in a smart way by people that know how it works (unfortunately it is not = always the case with BGP and we can see absurd announcements everyday), that no configuration mistake are = performed (which can be enforced if we ensure security in the mappings and appropriate mapping system, but this = is another story) and if we limit the=20 max-deaggregation into /24 for IPv4. In IPv6 I would not announce = anything as it is still blurry how IPv6 BGP will really look like (do we really conserve the aggregation we have today?). Does it go in favor of these studies or not? If not, could you discuss = with us off-list to design a worst case scenario that we can study to see how the ITRs would behave? Thank you for the feedback, Damien Saucez >=20 > Ross From jnc@mercury.lcs.mit.edu Thu Jul 14 15:07:57 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4294F21F8B56 for ; Thu, 14 Jul 2011 15:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJTYZGDMtbLo for ; Thu, 14 Jul 2011 15:07:56 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA321F8B51 for ; Thu, 14 Jul 2011 15:07:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 71B1D18C12B; Thu, 14 Jul 2011 18:07:50 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110714220750.71B1D18C12B@mercury.lcs.mit.edu> Date: Thu, 14 Jul 2011 18:07:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 22:07:57 -0000 > From: Ross Callon > The papers that I read both assume that the granularity of the > EID-to-RLOC tables will be the same as the granularity of the current > top level BGP routing table. If this assumption is wrong, then the > results will be correspondingly inaccurate. > To me it seems highly unlikely that this assumption is within an order > of magnitude of being correct. Yes and no. The papers do assume that the granularity is basically (see below) the same (i.e. the size profile of the mapping entries matches that of BGP routing table), but apart from that, I'm not sure they support the implicit contention that caches will therefore usually be much larger than BGP routing tables. Looking at, for instance, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System" (which has extensive trace-drive simulations) we read the following (pp. 13, 16): "we removed from the iPlane dataset the more specific prefixes that are mostly advertised for traffic engineering purposes [2] and wouldn't be advertised with LISP. A total number of 112,233 prefixes are assigned based on originating AS to their respective xTR[s] ... During our simulations the maximum number of mapping cache entries reached was 22,993 and 15,011 for the two traces. This is an order of magnitude less than routes in the DFZ" A couple of observations. First, the first step taken (dropping TE more-specifics) likely biased their BGP dataset towards larger prefixes (i.e. somewhat violating the assumption that "the size profile of the mapping entries matches that of BGP routing table"), but I will hereafter ignore this since it's probably second order. The more interesting observtion is that the cache size (on two quite large, eclectic sites) is a factor of at least 5 smaller than the overall routing table. So even if there is some 'mapping table bloat' compared to the BGP DFZ routing table as a whole (i.e. more mapping entries, system-wide, than there are BGP routes), these measured results suggest that even a eventual overall quite large bloat factor will still not result in tables that are larger than existing BGP tables. Of course, this 'downsized working set' pattern (which is a topic in itself, which is not explored at length here - there are good reasons why most sites will have smaller working sets, proportionately, in a growing Internet) will not hold for absolutely all sites; large content providers will likely see working sets which are much larger. However, such sites almost always have specialized infrastructure anyway, and it's not clear to me that their inability to use 'off the peg' solutions which work for everyone else is really a problem - it certainly doesn't seem to be for other aspects of their operations. Noel From jsw@inconcepts.biz Fri Jul 15 15:11:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7A21F8AF6 for ; Fri, 15 Jul 2011 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUwoJZD22FEn for ; Fri, 15 Jul 2011 15:11:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4D21F8AE4 for ; Fri, 15 Jul 2011 15:11:48 -0700 (PDT) Received: by vws12 with SMTP id 12so1656716vws.31 for ; Fri, 15 Jul 2011 15:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.138 with SMTP id w10mr4274309vdt.43.1310767908298; Fri, 15 Jul 2011 15:11:48 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Fri, 15 Jul 2011 15:11:48 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> Date: Fri, 15 Jul 2011 18:11:48 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 22:11:50 -0000 On Thu, Jul 14, 2011 at 4:03 AM, Damien Saucez wrote: > On 14 Jul 2011, at 04:55, Ross Callon wrote: >> To me it seems highly unlikely that this assumption is within an order o= f magnitude of being correct. > > At a first glance, the assumption might look bad, but I believe it is not= the case. Indeed, the evaluation are made You forget that a feature of LISP is to make multi-homing SOHO sites cheaper and easier, therefore increasing their number dramatically. If I can multi-home using LISP with my cable modem and my DSL, I will. Many "power users" will at their homes, to say nothing of branch offices and small businesses, which today do not warrant multiple, expensive ISP connections that offer speed, economy, and the capability for multi-homing. To assume the number of multi-homed end-sites won't grow by 10x is foolish. I believe we would see more than 100x growth, but even 10x, plus the cache problems identified, make LISP very much impractical for content providers. On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez wrote: > With "simple arithmetic", BGP cannot work, however, it works in practice = because > theory and practice are not the same. LISP is not perfect, and none of th= e protocols 360k prefixes, 360k FIB slots. Yes, if you have a flow-based BGP router in the DFZ, depending on its implementation, it may work poorly (Foundry IronCore, for example) and it may be trivial to disable with DoS traffic. However, LISP proposes to create a situation where the ITR should never know all mappings, must be able to hold negative replies from the MS, and thus increases the amount of FIB required (in worst case, which is real-world for content networks, they do receive DoS and have to deal with it) beyond the maximum number of possible mappings. As I have shown, this is problematic even if the number of mappings wouldn't explode due to SOHO multi-homing. On Thu, Jul 14, 2011 at 1:20 AM, Damien Saucez wrote: > Currently, when a map-request is sent, you receive the mapping for the > longest-match prefix corresponding. So why not changing to receive a > Map-Reply that contains as today the reply to the request + the a > negative-mapping with the longest-match prefix of the RIR that contains > this. The RIR knows how it assigns the prefixes, so it is easy to provide= this. Your idea is similar to my proposed fix and would reduce the "waste" caused by negative mappings. I don't agree that it is savvy to make the reply necessarily based on RIR assignment strategy (one can imagine many reasons where this may not be ideal) but think the router should be able to request what portion of the possible routing table it wants. Flexibility in the protocol specification, so vendors can implement what they choose, would be beneficial. On Thu, Jul 14, 2011 at 1:41 AM, Eliot Lear wrote: > In the first instance, let me suggest that the whole point of LISP is to > disentangle memory consumption from number of reachable points on the > Internet, but rather bound it to the number of sites actually being > reached. =A0That is what induces the concern that Jeff has raised with th= e > 2nd discussion. =A0What Jeff has described is a variation of the classic > reflection attack. =A0This is, IMHO, probably worth noting more > explicitly, as an area for future work. I encourage you to also keep in mind that, if an ETR should be able to verify that an ITR is a legitimate origin point for traffic sourced from a given address, ETRs will also be subject to the same cache problems. Except the ETR will be worse / more vulnerable, because you don't need any packet reflection to exploit it. I understand that the ideas for possibly preventing spoofing of packets are not well evolved yet, but they must take this into account. You are not even able to do loose uRPF checking on the inner-source-address of incoming packets without exposing the ETR to trivial DoS. On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez wrote: > LISP is definitely more than just a new way of doing VPNs. I am really so= rry if > you cannot see the fundamentals changes that a Map-and-Encap paradigm > brings to the way networks are managed. LISP is just an instantiation of = this I simply see that a hard, underlying problem has not been addressed. Touting the potential for LISP to bring new capabilities, on Internet-scale, without having considered the implications of Internet-scale DDoS, is either ignorant or irresponsible. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From damien.saucez@uclouvain.be Sat Jul 16 00:27:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9745E21F8631 for ; Sat, 16 Jul 2011 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lt4Ov71M7se for ; Sat, 16 Jul 2011 00:27:09 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37621F84DD for ; Sat, 16 Jul 2011 00:27:08 -0700 (PDT) Received: from [192.168.1.3] (172.174-247-81.adsl-dyn.isp.belgacom.be [81.247.174.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B6DE71C552A; Sat, 16 Jul 2011 09:27:04 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be B6DE71C552A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310801224; bh=BXoT1C7TiEdPzQs1zryrMZro0aj0FCbCykVewzNlzXI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vaoSn8Yh9DoNKlkn+V8e8RuhNPmvKxbzrDeAzPmm55viyjL+Li3xiyZDhTCKzuxOx juFoV276r9Ym8WkLi8UzNMl5CqPClwKKmiRcqHBLWHbIkrQX5JH13E3x8SXN6Zklbc nCHN/aMkBMydIigVXyELiBgOAKDQASQiy/oqcnrM= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <20110714220750.71B1D18C12B@mercury.lcs.mit.edu> Date: Fri, 15 Jul 2011 21:38:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <10123F8D-A902-4C5F-80A2-25EF9043E558@uclouvain.be> References: <20110714220750.71B1D18C12B@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B6DE71C552A.A0331 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 07:27:10 -0000 Noel, On 15 Jul 2011, at 00:07, Noel Chiappa wrote: >> From: Ross Callon >=20 >> The papers that I read both assume that the granularity of the >> EID-to-RLOC tables will be the same as the granularity of the current >> top level BGP routing table. If this assumption is wrong, then the >> results will be correspondingly inaccurate. >> To me it seems highly unlikely that this assumption is within an = order >> of magnitude of being correct. >=20 > Yes and no. The papers do assume that the granularity is basically = (see > below) the same (i.e. the size profile of the mapping entries matches = that of > BGP routing table), but apart from that, I'm not sure they support the > implicit contention that caches will therefore usually be much larger = than > BGP routing tables. >=20 > Looking at, for instance, "LISP-TREE: A DNS Hierarchy to Support the = LISP > Mapping System" (which has extensive trace-drive simulations) we read = the > following (pp. 13, 16): >=20 > "we removed from the iPlane dataset the more specific prefixes that = are > mostly advertised for traffic engineering purposes [2] and wouldn't = be > advertised with LISP. A total number of 112,233 prefixes are assigned > based on originating AS to their respective xTR[s] > ... > During our simulations the maximum number of mapping cache entries = reached > was 22,993 and 15,011 for the two traces. This is an order of = magnitude > less than routes in the DFZ" >=20 > A couple of observations. First, the first step taken (dropping TE > more-specifics) likely biased their BGP dataset towards larger = prefixes (i.e. > somewhat violating the assumption that "the size profile of the = mapping > entries matches that of BGP routing table"), but I will hereafter = ignore this > since it's probably second order. >=20 You are right, and we had a long discussion to determine if it was ok to do so. At the end, I think that in the particular case of LISP-Tree it = was reasonable to do so. (i) de-aggregation is an artifact of BGP (e.g., = impossible to do requester specific Map-Replies, only one best route...) (ii) half = of BGP is /24, meaning that the other halt is not /24 and an important = proportion of the non /24 prefixes are less-specific than other BGP prefixes. (iii) = the LISP-Tree paper assumed that the prefixes could be assigned in a smart way (no legacy). On the contrary the Conext'07 and Networking'11 papers of Iannone et al. consider /BGP granularity as theses papers are = focusing on the cache stress, the results do not show a dramatic difference in = the results between the papers (one trace in the LISP-Tree paper comes from the same network than in the "On the Cost of Caching Locator/ID Mappings (Conext'07)" paper, except that LISP-Tree uses a more recent trace with = an higher bandwidth consumption so more packets). > The more interesting observtion is that the cache size (on two quite = large, > eclectic sites) is a factor of at least 5 smaller than the overall = routing > table. So even if there is some 'mapping table bloat' compared to the = BGP DFZ > routing table as a whole (i.e. more mapping entries, system-wide, than = there > are BGP routes), these measured results suggest that even a eventual = overall > quite large bloat factor will still not result in tables that are = larger than > existing BGP tables. Yes, and one even more interesting observation made by Luigi in his Networking'11 paper is that even if we also install mappings for the = incoming traffic (for security checks) the size remains acceptable even though = scans were present. So the conclusion I would have is that the cache size is not really a = problem as long as we ensure that it cannot be attacked (this is why we are = actively working on the security topic). And actually this result is not bound to = LISP or the cache technology but to the traffic's characteristic. Indeed, the = traffic is known to have a relatively strong spacial and temporal locality. So I = think that the real question with the cache is related to the mapping = retrieval: what if we do not have a mapping in the cache. Drop is not always a good = option, buffering is not always possible and forwarding is maybe not achievable = for scalability reasons (r.i.p. data-probe). Thank you, Damien Saucez >=20 > Of course, this 'downsized working set' pattern (which is a topic in = itself, > which is not explored at length here - there are good reasons why most = sites > will have smaller working sets, proportionately, in a growing = Internet) will > not hold for absolutely all sites; large content providers will likely = see > working sets which are much larger. However, such sites almost always = have > specialized infrastructure anyway, and it's not clear to me that their > inability to use 'off the peg' solutions which work for everyone else = is > really a problem - it certainly doesn't seem to be for other aspects = of their > operations. >=20 > Noel From damien.saucez@uclouvain.be Sat Jul 16 07:17:18 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04121F8581 for ; Sat, 16 Jul 2011 07:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIOV3Gy6WtCm for ; Sat, 16 Jul 2011 07:17:17 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1835421F857E for ; Sat, 16 Jul 2011 07:17:17 -0700 (PDT) Received: from mail.sgsi.ucl.ac.be (mmp-3-1.sipr-dc.ucl.ac.be [10.1.3.8]) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTP id ACE3B1C5443; Sat, 16 Jul 2011 16:17:10 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be ACE3B1C5443 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310825830; bh=8LrPXifmJMMVf0WRBT165BNhi6rbb7MIaGyfv6Gidp0=; h=Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ysuMotlpYBsF/8sPKei2bZ5wjNxNfsDNmxU0XNCAFL7BSC0crgJAIQJ3HgLAwXmFI TdZnB/fJviXewvn5RLNA8nSxPm+fa7Ut8CrUEaivyyp70PGCdtjnRy7xSKGtfEpaBN LSDKrtr1ioGfbN4RxX7edC3FHsidxD3RYt6BfJq8= Received: from 195.81.124.31 (SquirrelMail authenticated user dsaucez) by mmp.sipr-dc.ucl.ac.be with HTTP; Sat, 16 Jul 2011 16:17:10 +0200 Message-ID: <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> In-Reply-To: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> Date: Sat, 16 Jul 2011 16:17:10 +0200 From: "Damien Saucez" To: "Jeff Wheeler" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-SGSI-MailScanner-ID: ACE3B1C5443.A9F36 X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.384, requis 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_00 -1.60, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VERIFIED -1.00, SARE_MILLIONSOF 0.32) X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 14:17:18 -0000 Dear Jeff, > On Thu, Jul 14, 2011 at 4:03 AM, Damien Saucez > wrote: >> On 14 Jul 2011, at 04:55, Ross Callon wrote: >>> To me it seems highly unlikely that this assumption is within an order >>> of magnitude of being correct. >> >> At a first glance, the assumption might look bad, but I believe it is >> not the case. Indeed, the evaluation are made > > You forget that a feature of LISP is to make multi-homing SOHO sites > cheaper and easier, therefore increasing their number dramatically. > If I can multi-home using LISP with my cable modem and my DSL, I will. > Many "power users" will at their homes, to say nothing of branch > offices and small businesses, which today do not warrant multiple, > expensive ISP connections that offer speed, economy, and the > capability for multi-homing. To assume the number of multi-homed > end-sites won't grow by 10x is foolish. I believe we would see more > than 100x growth, but even 10x, plus the cache problems identified, > make LISP very much impractical for content providers. > Actually, the very nature of Internet traffic make this a non-problem. Indeed, the heavy tail nature of the spacial locality distribution in the Internet ensures that, in general, only the big networks will have to deal with a huge number of client. And if your network is big, it is very likely that it will have many entry points and that these entry point are topologically close to the clients meaning that each entry point will actually not have to deal with millions of clients. Don't forget that you have to think in term of locality with LISP. If you don't you will kill the paradigm. Not because it is bad but because your interepretation is incorrect. LISP is not BGP! So if you don't believe me about how the traffic is on the Internet, I think you can believe the harbor study (data from hexabytes of traffic in real networks). What does the study show? Simply that the traffic converges to a few buch of CDNs (actually the study shows much more than that, but only this point is important for now). So yes you will see a lot of SOHOs but only the big CDNs will have to deal with an important amount of entries, not the other networks and for the CDN, believe me or not, but the routers they are using will be able to deal with even millions of mappings (which is unlikelly as the load is spread over several routers). Actually, a SOHO has in general a xTR (ITR and ETR merged) and the traffic is relativerly symetric in term destinations/sources (not volume but we don't care for the cache) as basically flows are bi-directional. In addition, the SOHO tend to communicate with CDNs not with other SOHOs. Feel free to provide me data that prove the opposite. > On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez > wrote: >> With "simple arithmetic", BGP cannot work, however, it works in practice >> because >> theory and practice are not the same. LISP is not perfect, and none of >> the protocols > > 360k prefixes, 360k FIB slots. Yes, if you have a flow-based BGP > router in the DFZ, depending on its implementation, it may work poorly > (Foundry IronCore, for example) and it may be trivial to disable with > DoS traffic. > Pointless remark. It is trivial that if you are not doing a good implementation your router will blow out. We are obviously considering that state of the art techniques will be used by the guys in charge of implementing LISP! > However, LISP proposes to create a situation where the ITR should > never know all mappings, must be able to hold negative replies from > the MS, and thus increases the amount of FIB required (in worst case, > which is real-world for content networks, they do receive DoS and have > to deal with it) see above... > beyond the maximum number of possible mappings. As I > have shown, this is problematic even if the number of mappings > wouldn't explode due to SOHO multi-homing. > And I showed that it was not a so big problem if you are deploying the system in a smart way. > On Thu, Jul 14, 2011 at 1:20 AM, Damien Saucez > wrote: >> Currently, when a map-request is sent, you receive the mapping for the >> longest-match prefix corresponding. So why not changing to receive a >> Map-Reply that contains as today the reply to the request + the a >> negative-mapping with the longest-match prefix of the RIR that contains >> this. The RIR knows how it assigns the prefixes, so it is easy to >> provide this. > > Your idea is similar to my proposed fix and would reduce the "waste" > caused by negative mappings. I don't agree that it is savvy to make > the reply necessarily based on RIR assignment strategy (one can > imagine many reasons where this may not be ideal) but think the router > should be able to request what portion of the possible routing table > it wants. Flexibility in the protocol specification, so vendors can > implement what they choose, would be beneficial. RIR was an example, please be constructive in your remarks. > > On Thu, Jul 14, 2011 at 1:41 AM, Eliot Lear wrote: >> In the first instance, let me suggest that the whole point of LISP is to >> disentangle memory consumption from number of reachable points on the >> Internet, but rather bound it to the number of sites actually being >> reached.  That is what induces the concern that Jeff has raised with the >> 2nd discussion.  What Jeff has described is a variation of the classic >> reflection attack.  This is, IMHO, probably worth noting more >> explicitly, as an area for future work. > > I encourage you to also keep in mind that, if an ETR should be able to > verify that an ITR is a legitimate origin point for traffic sourced > from a given address, ETRs will also be subject to the same cache > problems. Except the ETR will be worse / more vulnerable, because you > don't need any packet reflection to exploit it. I understand that the > ideas for possibly preventing spoofing of packets are not well evolved > yet, but they must take this into account. You are not even able to > do loose uRPF checking on the inner-source-address of incoming packets > without exposing the ETR to trivial DoS. Jeff, please, before shouting everywhere that we are dumb, read ALL the documents related to LISP. In the draft about security threats we explain that ETR should make sanity checks to protect against spoofing. We even present different type of spoofing and ways to protect the routers. And in a paper in Networking'11 the authors show that in a (real!) network, activating such sanity check at the ETRs is not an issue and the caches do not blow out. Again if you have data to give us to proof your thoughts, feel free to provide me them and I will work on them to see if we really are as stupid as you pretend. I would be the first happy to show a negative result, my work is not to provide positive of negative results but simply to provide facts. > On Thu, Jul 14, 2011 at 1:55 AM, Damien Saucez > wrote: >> LISP is definitely more than just a new way of doing VPNs. I am really >> sorry if >> you cannot see the fundamentals changes that a Map-and-Encap paradigm >> brings to the way networks are managed. LISP is just an instantiation of >> this > > I simply see that a hard, underlying problem has not been addressed. > Touting the potential for LISP to bring new capabilities, on > Internet-scale, without having considered the implications of > Internet-scale DDoS, is either ignorant or irresponsible. > Since we never heard about you before a few weeks, I think that you just discovered LISP. On my side, I started working on LISP in '07 and since then I consider the security implications with LISP. We have internal documents that explore the different ways to secure the mappings and to avoid spoofing and we are still studying what is the best OPERATIONAL vs REALISTIC solution. I am also the author and co-author of several IETF drafts and scientific papers about the LISP security and the impact of scans on LISP. You are probably not aware of that but a draft becomes a WG document if and only if the majority of people in the WG consider that it is worth working on it (many of my drafts have been dropped, this is the life of an IETF draft). As several WG drafts are about security in the LISP WG, it means that a majority of the people working in the LISP WG consider that security is worth working on. Could you please provide arguments and proofs of what you claim and try also to know the LISP state of the art to be sure that it is not already done? If you do not provide more argumented discussion, I will have to stop answering your mails. Thank you for you interest in LISP Regards, Damien Saucez > -- > Jeff S Wheeler > Sr Network Operator  /  Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From robert@raszuk.net Sat Jul 16 11:14:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47721F8745 for ; Sat, 16 Jul 2011 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=-4.107, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbuPWKSX7iAO for ; Sat, 16 Jul 2011 11:14:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0021F86E6 for ; Sat, 16 Jul 2011 11:14:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABbUIU6rRDoG/2dsb2JhbABShEmjLHeIfKJOjRyQJIErhAKBDwSSZoUBi1Y X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3607031" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2011 18:14:13 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6GIEB7s024247; Sat, 16 Jul 2011 18:14:11 GMT Message-ID: <4E21D4F6.6020008@raszuk.net> Date: Sat, 16 Jul 2011 20:14:14 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Damien Saucez References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> In-Reply-To: <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 18:14:14 -0000 Hi Damien, > Actually, the very nature of Internet traffic make this a non-problem. > Indeed, the heavy tail nature of the spacial locality distribution in the > Internet ensures that, in general, only the big networks will have to deal > with a huge number of client. And if your network is big, it is very > likely that it will have many entry points and that these entry point are > topologically close to the clients meaning that each entry point will > actually not have to deal with millions of clients. Don't forget that you > have to think in term of locality with LISP. If you don't you will kill > the paradigm. Not because it is bad but because your interepretation is > incorrect. LISP is not BGP! So if you don't believe me about how the > traffic is on the Internet, I think you can believe the harbor study (data > from hexabytes of traffic in real networks). What does the study show? > Simply that the traffic converges to a few buch of CDNs (actually the > study shows much more than that, but only this point is important for > now). I am a bit puzzled by your above points. You seems to be making a future claims based on historical observations statistically averaged with time. I am afraid the point Jeff is making is not about any average .. it's about a peak. I think any solution by design must consider that even if I am a very small home site my xTRs must be able to deal with millions of clients .. as this is not query, but replies which will go into millions of Internet destinations the moment google indexes some very popular content on my web server. Just consider the case where I am multi-homed and my web queries are coming over different ETR then my replies are taking ITR. Many thx, R. From jsw@inconcepts.biz Sun Jul 17 01:37:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB2821F8640 for ; Sun, 17 Jul 2011 01:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNpjVBLRzEeB for ; Sun, 17 Jul 2011 01:37:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC0F021F85CE for ; Sun, 17 Jul 2011 01:37:48 -0700 (PDT) Received: by vxi40 with SMTP id 40so2354713vxi.31 for ; Sun, 17 Jul 2011 01:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.47 with SMTP id r15mr5113937vdf.110.1310891867293; Sun, 17 Jul 2011 01:37:47 -0700 (PDT) Received: by 10.220.179.3 with HTTP; Sun, 17 Jul 2011 01:37:47 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> Date: Sun, 17 Jul 2011 04:37:47 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 08:37:50 -0000 On Sat, Jul 16, 2011 at 10:17 AM, Damien Saucez wrote: > Actually, the very nature of Internet traffic make this a non-problem. This is incorrect, because *any* content network, and any subscriber access platform, must be able to deal with the threat of DoS attacks. If you re-design the Internet in such a way that it becomes trivial to disable any service or any end-user with a relatively small DoS, and that is the direct impact of LISP on a large scale, then every network which wishes to avoid being subject to regular outages must build the large xTR infrastructure you say a few CDNs will build. DoS attacks > 10Gbps are so common today, they do not even attract attention. This can be handled by today's networks simply by having enough capacity, but without xTR infrastructure able to support all possible mappings in FIB without a need for cache, DoS attacks in a scaled-out LISP future would be measured by flow-churn rate. A router that can do > 15M FIB updates/second does not exist, and in fact, FIB update rates would have to go up by three orders of magnitude to handle a worst-case scenario where the cache hit rate is near zero. If you scale up the number of prefixes / end-sites from 360k to 36M, as I suggest is likely if SOHO multi-homing becomes trivial for the end-sites, even routers with large FIB by today's standards will have quite low cache hit rate when subject to DoS (or simply a large amount of end-user traffic.) The folks who often quip that vendors can easily increase the size of FIB to deal with the increasing BGP DFZ generally mean vendors can easily and inexpensively double the FIB. They certainly cannot grow it by 100x on today's IC fabrication processes. If you assume most of the Internet is only having to deal with a few tens of thousands of flows and a high cache hit rate, it is easy to imagine that LISP is a wonderful idea. These assumptions completely break down when faced with the reality of DoS, and get far worse when the number of end-sites scales up. You continue to ignore both of these problems, which are directly related to the fact that LISP has not addressed the fundamental issue of an increasing number of end-sites. > Pointless remark. It is trivial that if you are not doing a good > implementation your router will blow out. We are obviously considering > that state of the art techniques will be used by the guys in charge of > implementing LISP! LISP has not advanced the state of the art in flow cache management. It has not produced a way of reducing the ultimate number of end-sites, either; and in fact should increase them significantly if LISP is successful. > And I showed that it was not a so big problem if you are deploying the > system in a smart way. >> Your idea is similar to my proposed fix and would reduce the "waste" >> caused by negative mappings. =A0I don't agree that it is savvy to make >> the reply necessarily based on RIR assignment strategy (one can >> imagine many reasons where this may not be ideal) but think the router >> should be able to request what portion of the possible routing table >> it wants. =A0Flexibility in the protocol specification, so vendors can >> implement what they choose, would be beneficial. > > RIR was an example, please be constructive in your remarks. If you don't think the above paragraph is constructive, then you have closed yourself to feedback. This exemplifies the problem operators perceive with "the IETF." Perhaps I should have said: * more negative cache optimization is possible if not limiting that to RIR assignment strategy * RIR assignment strategy may chance and require implementation updates (at worst) or configuration changes that may not be performed by operators: see problems getting new RIR IP blocks "de-bogoned" over the past few years * not all platforms need these complexities, for example, the SOHO xTR with a relatively low-speed connection that cannot be subject to a high flow churn rate, or is implemented on a general-purpose computing platform e.g. x86 >> I encourage you to also keep in mind that, if an ETR should be able to >> verify that an ITR is a legitimate origin point for traffic sourced >> from a given address, ETRs will also be subject to the same cache >> problems. =A0Except the ETR will be worse / more vulnerable, because you >> don't need any packet reflection to exploit it. =A0I understand that the >> ideas for possibly preventing spoofing of packets are not well evolved >> yet, but they must take this into account. =A0You are not even able to >> do loose uRPF checking on the inner-source-address of incoming packets >> without exposing the ETR to trivial DoS. > > Jeff, =A0please, before shouting everywhere that we are dumb, read ALL th= e > documents related to LISP. In the draft about security threats we explain > that ETR should make sanity checks to protect against spoofing. We even > present different type of spoofing and ways to protect the routers. And i= n > a paper in Networking'11 the authors show that in a (real!) network, > activating such sanity check at the ETRs is not an issue and the caches d= o > not blow out. Yes, the caches do blow out, due to the same problem with DoS reflecting out an ITR. The difference here is the act of attempting to verify source address (or even do loose uRPF) "blows out" the ETR cache, and there is no possibility to defend against it. Your analyses of "real" traffic are not based in reality without the inclusion of Internet-scale DDoS. In addition, they are further made worse because your group has not envisioned the "worst case LISP DoS" that specifically exploits cache vulnerabilities. These types of attack will not be represented by your analyses because of two reasons: * no LISP deployments yet and thus no real-world attacks against it yet, but they will come in the future if LISP ever becomes widely-deployed * no huge increase in the number of end-sites due to SOHO multi-homing, because that is not currently practical, but LISP promises to make it practical > Again if you have data to give us to proof your thoughts, feel free to You need to stop relying on traffic captures. Of course you won't see DoS specifically designed to exploit a vulnerability that does not exist in today's networks, but will with LISP deployed. And if you simply assume that only a few ultra-large CDNs will need to handle millions of flows, and all other sites are trivial, you are assuming that no other sites will ever see millions of flows due to DoS. That is wrong. > Since we never heard about you before a few weeks, I think that you just > discovered LISP. On my side, I started working on LISP in '07 and since I have been aware of LISP development for many years. I only took more interest in it recently, when a colleague told me what great progress had been made. I examined the current work in more detail, and found that the same fundamental problems which existed years ago are still here. The reason why is simple: your group has a great deal of vision about how a future LISP-based Internet could function, but you continually fail to consider the negative effects of DoS, and you do not have a basic understanding of how the data-plane actually works, which is necessary to envision how the xTR will perform when subject to such DoS. The reason I care is because IPv6 gave us an identical problem on a more limited scope, by setting the expectation that LANs (or all networks) should be /64. Unfortunately, a parallel problem exists with IPv6 ND cache exploits when deploying /64 networks in the real world. It is possible to fix this (SeND, more router/switch knobs, etc.) and it is possible to simply deploy networks differently to avoid the problem. However, with LISP, the problem is of global scope and it may not be possible to fix if LISP scales up. > Could you please provide arguments and proofs of what you claim and try > also to know the LISP state of the art to be sure that it is not already > done? If you do not provide more argumented discussion, I will have to > stop answering your mails. How do you expect an ETR to validate the origin of packets when subject to an attack designed to cause mapping churn? Imagine that you have an Internet-scale LISP network, with perhaps 3M or 30M end-sites and possible mappings, and I am sending you 15Mpps of packets which all appear to originate from different end-sites. No router today will be able to mange this in FIB, so cache churn will result. Now reduce the size of that attack from 15Mpps (trivial today) to an even smaller 200Kpps. This is still 10x faster than modern routers can handle FIB churn, at a rate of around 20K updates/second. How will the ETR be able to validate source addresses under this tiny assault, which may originate from literally one co-located server with a GbE connection, without even fully utilizing such connection? The answer is it cannot. Not only can the ETR not validate source addresses, it can't even discard packets which originate from impossible source addresses (loose uRPF check) because it is not able to determine whether or not these source addresses are even present in the mapping system quickly enough. That is the state-of-the-art today. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From damien.saucez@uclouvain.be Mon Jul 18 00:58:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445F321F8B77 for ; Mon, 18 Jul 2011 00:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-SZyAySxhvg for ; Mon, 18 Jul 2011 00:57:56 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A150B21F8B73 for ; Mon, 18 Jul 2011 00:57:55 -0700 (PDT) Received: from sleipnier.dhcp.info.ucl.ac.be (sleipnier.dhcp.info.ucl.ac.be [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 05C1D11E3C8; Mon, 18 Jul 2011 09:57:40 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 05C1D11E3C8 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310975860; bh=hP9T+H/U/iazL7hPws/UXgr4ZHS8H5shcTwUtOIjLDo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PANzXCRQDkaV6U5VUPZZTCGh7jNxyMSSwsWM/RiMVlrmOYTPpiu1+COQWWpNMY6f9 SI0RQwA9rG4p8Io7x3BQ7imuY+8qV4crkMbLZ2EQlvMBO8SGe8WDqt9NWed/JcSQas cwb2YfwrKeFioyPU3zZxX37sRlxoWElaW+3HE1AU= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4E21D4F6.6020008@raszuk.net> Date: Mon, 18 Jul 2011 09:57:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 05C1D11E3C8.A5F59 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:58:00 -0000 Robert, On 16 Jul 2011, at 20:14, Robert Raszuk wrote: > Hi Damien, >=20 >> Actually, the very nature of Internet traffic make this a = non-problem. >> Indeed, the heavy tail nature of the spacial locality distribution in = the >> Internet ensures that, in general, only the big networks will have to = deal >> with a huge number of client. And if your network is big, it is very >> likely that it will have many entry points and that these entry point = are >> topologically close to the clients meaning that each entry point will >> actually not have to deal with millions of clients. Don't forget that = you >> have to think in term of locality with LISP. If you don't you will = kill >> the paradigm. Not because it is bad but because your interepretation = is >> incorrect. LISP is not BGP! So if you don't believe me about how the >> traffic is on the Internet, I think you can believe the harbor study = (data >> from hexabytes of traffic in real networks). What does the study = show? >> Simply that the traffic converges to a few buch of CDNs (actually the >> study shows much more than that, but only this point is important for >> now). >=20 > I am a bit puzzled by your above points. You seems to be making a = future claims based on historical observations statistically averaged = with time. I am afraid the point Jeff is making is not about any average = .. it's about a peak. >=20 You are partially right as in the different studies, the cache load is = considered on average, in general 1 minute. However the averaging periods are = shorter than the TTL/timers used for the caches so the instantaneous size of the = cache would not change dramatically (probably a 1 or 2 % increase). What could change more is the "churn" (i.e., the instantaneous cache size change) = as we are smoothing the curves thus lowering the derivative of the underlying = cache size function. So for the studied networks, the cache sizes obtained are very close to = the reality (under our EID prefix attribution assumptions of course). > I think any solution by design must consider that even if I am a very = small home site my xTRs must be able to deal with millions of clients .. = as this is not query, but replies which will go into millions of = Internet destinations the moment google indexes some very popular = content on my web server. Just consider the case where I am multi-homed = and my web queries are coming over different ETR then my replies are = taking ITR. I am not sure I understand perfectly what you mean. Why should a small = home site would have millions of destinations? It would mean that you observe = at least millions of flows within your small network. Even in campus networks = like our university we do not observe millions of concurrent flows. In one day we = have in general 3 million different IP addresses in our network and there is no = mechanism to limit the traffic but more interestingly, during 5 minute periods, we = observe peaks at around 60K to 70K concurrent destination addresses and peaks = to 1.2M L3 flows and interestingly, from 5min time slots to 5min time slots, we can see big variations (having 60K destination then 20K then 40K ... is common) maning that actually the ground traffic that would = stay in the cache for what ever TTL is not so important. Indeed, a top few (~ = thousands) destinations are contacted all the time, while the rest could be seen as = noise with short period of time (from a few seconds to a few hours). So a good = cache eviction algorithm should solve most of the case. Regarding the cache = size, I think that the mistake is in the specs, where it is recommended to have = a TTL of one day. =46rom the temporal locality of Internet traffic, we can = say that this choice is meaningless. xTR should be able to fix themselves the TTL of = the mappings they install in their cache (TTL_cache <=3D TTL_Map-Reply). Nevertheless, it is true that a site like google may have to deal with = millions of mappings while indexing. I do not know how google work for indexing, but = I presume that this million of pages are not indexed in one minute by a single = machine.=20 Probably that the indexing takes several hours (days?) and is from = different machines with load balancers. Probably that the indexing of a site takes at much = a few tens of minutes, the ITR could thus limit the TTL to that amount of time. In = addition, if=20 load balancers are actually used, one could imagine to use these LB = directly as xTRs. Another case where you can observe peaks of destinations is with mails, = if your server is attacked and becomes a relay for spams, it can potentially = have to contact a huge number of destinations. It is a problem, but I think that = the problem is not LISP but the way the server is managed. But you and Jeff are right that LISP has a big problem in case of sort = of flash crowds. The question is to know what will die first, the cache or the services = that are flash crowded. Such peaks can also be done with DDoS and this is why we = are working on techniques to avoid spoofing with LISP. And yes, we have to = be honest we do not have the perfect solution now for this problem. Thank you, Damien Saucez >=20 > Many thx, > R. From robert@raszuk.net Mon Jul 18 01:12:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4021F8B64 for ; Mon, 18 Jul 2011 01:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-4.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U09ZlNHYjexj for ; Mon, 18 Jul 2011 01:12:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE821F8B5F for ; Mon, 18 Jul 2011 01:12:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG7qI06tJXHA/2dsb2JhbABTp213iHylSp1MhjwEkmaFAYtW X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="3868474" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2011 08:12:44 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6I8CgEL005476; Mon, 18 Jul 2011 08:12:43 GMT Message-ID: <4E23EAFB.3080604@raszuk.net> Date: Mon, 18 Jul 2011 10:12:43 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Damien Saucez References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> In-Reply-To: <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 08:12:50 -0000 Hi Damien, Many thx for your reply. Let me clarify ... > I am not sure I understand perfectly what you mean. Why should a small home > site would have millions of destinations? It would mean that you observe at least > millions of flows within your small network. Yes. Imagine if you or me announce wiki-leaks-2 content on our IPv4/IPv6 home web server. I think number of flows will explode. And imagine we are lucky users of FTTH so no bandwith issue :) Moreover those may not be DOS or spoofing. Those may be legitimate addresses. And I do not think the server will die. And I am not saying LISP will or will not be able to handle it. I am just asking how it will handle it ;) Maybe the answer is to in the moment of exceeding capacity threshold of any xTR push some of the traffic to few bigger proxies ... just a thought. Cheers, R. Even in campus networks like our > university we do not observe millions of concurrent flows. In one day we have in > general 3 million different IP addresses in our network and there is no mechanism > to limit the traffic but more interestingly, during 5 minute periods, we observe > peaks at around 60K to 70K concurrent destination addresses and peaks to 1.2M > L3 flows and interestingly, from 5min time slots to 5min time > slots, we can see big variations (having 60K destination then 20K then > 40K ... is common) maning that actually the ground traffic that would stay in the > cache for what ever TTL is not so important. Indeed, a top few (~ thousands) > destinations are contacted all the time, while the rest could be seen as noise > with short period of time (from a few seconds to a few hours). So a good cache > eviction algorithm should solve most of the case. Regarding the cache size, I > think that the mistake is in the specs, where it is recommended to have a TTL > of one day. From the temporal locality of Internet traffic, we can say that this > choice is meaningless. xTR should be able to fix themselves the TTL of the > mappings they install in their cache (TTL_cache<= TTL_Map-Reply). > > Nevertheless, it is true that a site like google may have to deal with millions of > mappings while indexing. I do not know how google work for indexing, but I presume > that this million of pages are not indexed in one minute by a single machine. > Probably that the indexing takes several hours (days?) and is from different machines > with load balancers. Probably that the indexing of a site takes at much a few tens of > minutes, the ITR could thus limit the TTL to that amount of time. In addition, if > load balancers are actually used, one could imagine to use these LB directly as > xTRs. > > Another case where you can observe peaks of destinations is with mails, if your > server is attacked and becomes a relay for spams, it can potentially have to > contact a huge number of destinations. It is a problem, but I think that the problem > is not LISP but the way the server is managed. > > But you and Jeff are right that LISP has a big problem in case of sort of flash crowds. > The question is to know what will die first, the cache or the services that are > flash crowded. Such peaks can also be done with DDoS and this is why we are > working on techniques to avoid spoofing with LISP. And yes, we have to be > honest we do not have the perfect solution now for this problem. > > Thank you, > > Damien Saucez > >> >> Many thx, >> R. > > > From damian.lukowski@rwth-aachen.de Mon Jul 18 02:06:44 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D78921F8B7E for ; Mon, 18 Jul 2011 02:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjOV4Xtmqezi for ; Mon, 18 Jul 2011 02:06:43 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA621F8B7C for ; Mon, 18 Jul 2011 02:06:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=iso-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LOI00BV0UN6TEB0@mta-2.ms.rz.RWTH-Aachen.de> for lisp@ietf.org; Mon, 18 Jul 2011 11:06:42 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.67,221,1309730400"; d="scan'208";a="125561961" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 18 Jul 2011 11:06:37 +0200 Received: from mail.tvk.rwth-aachen.de (fluchtweg.tvk.RWTH-Aachen.DE [137.226.143.2]) by smarthost.rwth-aachen.de (8.14.4+Sun/8.13.8/1) with ESMTP id p6I96ajd018946 for ; Mon, 18 Jul 2011 11:06:36 +0200 (CEST) Received: from localhost (unknown [127.0.0.1]) by mail.tvk.rwth-aachen.de (Postfix) with ESMTP id 815751815AC42 for ; Mon, 18 Jul 2011 08:59:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at tvk.rwth-aachen.de Received: from mail.tvk.rwth-aachen.de ([127.0.0.1]) by localhost (mail.tvk.rwth-aachen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5VEiZXqVPWvR for ; Mon, 18 Jul 2011 10:59:09 +0200 (CEST) Received: from mail.arcsin.de (unknown [137.226.143.254]) by mail.tvk.rwth-aachen.de (Postfix) with ESMTP id 363CB1815AA35 for ; Mon, 18 Jul 2011 10:59:09 +0200 (CEST) Received: from 149.224.132.21 (SquirrelMail authenticated user damian) by mail.arcsin.de with HTTP; Mon, 18 Jul 2011 10:59:09 +0200 Message-id: Date: Mon, 18 Jul 2011 10:59:09 +0200 From: Damian To: lisp@ietf.org User-Agent: SquirrelMail/1.4.21 X-Priority: 3 (Normal) Importance: Normal Subject: [lisp] LISP basic questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 09:28:30 -0000 Hi ML, I am trying to understand the concept of LISP and would like to pose some questions, if that is okay. Who exactly is supposed to run and configure ETRs and ITRs? In my understanding it is those organizations, who participate in global BGP routing, so basically those with their own ASes? What about smaller organizations who have their own RIPE-registered IP-net but are just one of many networks in a larger AS? I suppose, it does not make sense for such smaller organizations to set up their own ETRs/ITRs to serve the original purpose, as it wouldn't offload the Internet's global BGP table. Nevertheless, there are other benefits for smaller companies which run multiple sites. Site-to-site routing could be balanced for instance, if each site was multi-homed and multiple ETRs per site were available. I wonder however, what will happen if someone invests in several Nexus 7000 to leverage those benefits today, and some time later the AS owning provider has plans to set up his own LISP-infrastructure. Won't there be a problem with double-encap or similar? Best Regards Damian From luigi@net.t-labs.tu-berlin.de Mon Jul 18 03:33:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E42421F8B52 for ; Mon, 18 Jul 2011 03:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBFTVE81u6mU for ; Mon, 18 Jul 2011 03:33:45 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 93CCA21F8B3F for ; Mon, 18 Jul 2011 03:33:44 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 96BA570B3885; Mon, 18 Jul 2011 12:33:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: Date: Mon, 18 Jul 2011 12:33:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:33:45 -0000 On Jul 17, 2011, at 10:37 , Jeff Wheeler wrote: [snip] > > Your analyses of "real" traffic are not based in reality without the > inclusion of Internet-scale DDoS. Simply because was out of the scope of that work. This does not reduce in any way the value of the work itself. The work makes clear assumptions that well define the scope of the results. Luigi From damien.saucez@uclouvain.be Mon Jul 18 05:47:01 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF1A21F8B12 for ; Mon, 18 Jul 2011 05:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWTrC+74UL0X for ; Mon, 18 Jul 2011 05:46:57 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45C21F8AFE for ; Mon, 18 Jul 2011 05:46:57 -0700 (PDT) Received: from sleipnier.dhcp.info.ucl.ac.be (sleipnier.dhcp.info.ucl.ac.be [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7674411E405; Mon, 18 Jul 2011 14:46:53 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 7674411E405 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310993213; bh=dnAQz7Ii11BBfTrvtE8pUwS7nVVuBj1lRT6ylvd+1Mc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DeiN3bVHjqy4wZm69NPia5DM32cVmRwKAXgM4Zlm6uFcvBKXZ2tKTU4kU4b2obrW9 lGUf96jaREOPZw2V+m5Kpw9IedvnuJADFDIK/o2RWVyo4Ldc9jx4reiiiSS1qJ2a89 yy4rQQq0NPds1BjsUtdO4ckOMJq9BV71cq6gr2e8= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4E23EAFB.3080604@raszuk.net> Date: Mon, 18 Jul 2011 14:46:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 7674411E405.AF839 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:47:01 -0000 Hello, On 18 Jul 2011, at 10:12, Robert Raszuk wrote: > Hi Damien, >=20 > Many thx for your reply. >=20 > Let me clarify ... >=20 >> I am not sure I understand perfectly what you mean. Why should a = small home >> site would have millions of destinations? It would mean that you = observe at least >> millions of flows within your small network. >=20 > Yes. Imagine if you or me announce wiki-leaks-2 content on our = IPv4/IPv6 home web server. I think number of flows will explode. And = imagine we are lucky users of FTTH so no bandwith issue :) >=20 > Moreover those may not be DOS or spoofing. Those may be legitimate = addresses. And I do not think the server will die. >=20 > And I am not saying LISP will or will not be able to handle it. I am = just asking how it will handle it ;) Maybe the answer is to in the = moment of exceeding capacity threshold of any xTR push some of the = traffic to few bigger proxies ... just a thought. >=20 Thank you for the clarification, this is a nice example indeed! You are right that for such legitimate traffic there is problem as it = can be assimilated to a flash crowd. In you particular example, I think that it is the Map-Resolver or the control plane itself that will cause = the problems! If we consider the cache size it should be ok. If we have one million client *simultaneously* and that the system is stupid and stores the mapping records as-is, that all the requesters are IPv4 and have two rlocs, then 40MB of storage is required. It is especially what the small home routers have today, but it is not 1million times more than the memory they provide now, so it would not be too hard. But the control-plane in these routers would suffer and these boxes are in general pure software and have slow processors so I don't know if they will enjoy to update the cache at a rate higher than a few = hundreds entries per second. To be honest I don't know what could be achieved by such devices. And even if they are able to deal with this speed, it will = maybe be complicated for the boxes to find a MR that will not rate limit the = number of requests. So this goes in the direction of Jeff saying that the churn problem = should not be neglected. Thank you, Damien Saucez > Cheers, > R. >=20 >=20 >=20 > Even in campus networks like our >> university we do not observe millions of concurrent flows. In one day = we have in >> general 3 million different IP addresses in our network and there is = no mechanism >> to limit the traffic but more interestingly, during 5 minute periods, = we observe >> peaks at around 60K to 70K concurrent destination addresses and = peaks to 1.2M >> L3 flows and interestingly, from 5min time slots to 5min time >> slots, we can see big variations (having 60K destination then 20K = then >> 40K ... is common) maning that actually the ground traffic that would = stay in the >> cache for what ever TTL is not so important. Indeed, a top few (~ = thousands) >> destinations are contacted all the time, while the rest could be seen = as noise >> with short period of time (from a few seconds to a few hours). So a = good cache >> eviction algorithm should solve most of the case. Regarding the cache = size, I >> think that the mistake is in the specs, where it is recommended to = have a TTL >> of one day. =46rom the temporal locality of Internet traffic, we can = say that this >> choice is meaningless. xTR should be able to fix themselves the TTL = of the >> mappings they install in their cache (TTL_cache<=3D TTL_Map-Reply). >>=20 >> Nevertheless, it is true that a site like google may have to deal = with millions of >> mappings while indexing. I do not know how google work for indexing, = but I presume >> that this million of pages are not indexed in one minute by a single = machine. >> Probably that the indexing takes several hours (days?) and is from = different machines >> with load balancers. Probably that the indexing of a site takes at = much a few tens of >> minutes, the ITR could thus limit the TTL to that amount of time. In = addition, if >> load balancers are actually used, one could imagine to use these LB = directly as >> xTRs. >>=20 >> Another case where you can observe peaks of destinations is with = mails, if your >> server is attacked and becomes a relay for spams, it can potentially = have to >> contact a huge number of destinations. It is a problem, but I think = that the problem >> is not LISP but the way the server is managed. >>=20 >> But you and Jeff are right that LISP has a big problem in case of = sort of flash crowds. >> The question is to know what will die first, the cache or the = services that are >> flash crowded. Such peaks can also be done with DDoS and this is why = we are >> working on techniques to avoid spoofing with LISP. And yes, we have = to be >> honest we do not have the perfect solution now for this problem. >>=20 >> Thank you, >>=20 >> Damien Saucez >>=20 >>>=20 >>> Many thx, >>> R. >>=20 >>=20 >>=20 >=20 From robert@raszuk.net Mon Jul 18 06:04:00 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05A621F8BF8 for ; Mon, 18 Jul 2011 06:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=-3.521, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWotGkx8AQen for ; Mon, 18 Jul 2011 06:04:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E58BC21F8BF6 for ; Mon, 18 Jul 2011 06:03:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIMuJE6rRDoI/2dsb2JhbABUp3R3iHykBZ1yhjwEkmaFAYtW X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="scan'208";a="3934991" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2011 13:03:59 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6ID3v9t005066; Mon, 18 Jul 2011 13:03:57 GMT Message-ID: <4E242F3C.6060002@raszuk.net> Date: Mon, 18 Jul 2011 15:03:56 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Damien Saucez References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> In-Reply-To: <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:04:00 -0000 Hi Damien, > So this goes in the direction of Jeff saying that the churn problem > should not be neglected. Very much indeed. And to save one more email from Luigi .. I do not buy the argument that this is simply "out of scope" as this would really mean "out of practical reality". Cheers, R. > Hello, > > On 18 Jul 2011, at 10:12, Robert Raszuk wrote: > >> Hi Damien, >> >> Many thx for your reply. >> >> Let me clarify ... >> >>> I am not sure I understand perfectly what you mean. Why should a small home >>> site would have millions of destinations? It would mean that you observe at least >>> millions of flows within your small network. >> >> Yes. Imagine if you or me announce wiki-leaks-2 content on our IPv4/IPv6 home web server. I think number of flows will explode. And imagine we are lucky users of FTTH so no bandwith issue :) >> >> Moreover those may not be DOS or spoofing. Those may be legitimate addresses. And I do not think the server will die. >> >> And I am not saying LISP will or will not be able to handle it. I am just asking how it will handle it ;) Maybe the answer is to in the moment of exceeding capacity threshold of any xTR push some of the traffic to few bigger proxies ... just a thought. >> > > Thank you for the clarification, this is a nice example indeed! > > You are right that for such legitimate traffic there is problem as it can be > assimilated to a flash crowd. In you particular example, I think > that it is the Map-Resolver or the control plane itself that will cause the > problems! > > If we consider the cache size it should be ok. If we have > one million client *simultaneously* and that the system is stupid and > stores the mapping records as-is, that all the requesters are IPv4 and > have two rlocs, then 40MB of storage is required. It is especially what > the small home routers have today, but it is not 1million times more > than the memory they provide now, so it would not be too hard. > > But the control-plane in these routers would suffer and these boxes > are in general pure software and have slow processors so I don't know > if they will enjoy to update the cache at a rate higher than a few hundreds > entries per second. To be honest I don't know what could be achieved by > such devices. And even if they are able to deal with this speed, it will maybe > be complicated for the boxes to find a MR that will not rate limit the number > of requests. > > So this goes in the direction of Jeff saying that the churn problem should > not be neglected. > > Thank you, > > Damien Saucez > >> Cheers, >> R. >> >> >> >> Even in campus networks like our >>> university we do not observe millions of concurrent flows. In one day we have in >>> general 3 million different IP addresses in our network and there is no mechanism >>> to limit the traffic but more interestingly, during 5 minute periods, we observe >>> peaks at around 60K to 70K concurrent destination addresses and peaks to 1.2M >>> L3 flows and interestingly, from 5min time slots to 5min time >>> slots, we can see big variations (having 60K destination then 20K then >>> 40K ... is common) maning that actually the ground traffic that would stay in the >>> cache for what ever TTL is not so important. Indeed, a top few (~ thousands) >>> destinations are contacted all the time, while the rest could be seen as noise >>> with short period of time (from a few seconds to a few hours). So a good cache >>> eviction algorithm should solve most of the case. Regarding the cache size, I >>> think that the mistake is in the specs, where it is recommended to have a TTL >>> of one day. From the temporal locality of Internet traffic, we can say that this >>> choice is meaningless. xTR should be able to fix themselves the TTL of the >>> mappings they install in their cache (TTL_cache<= TTL_Map-Reply). >>> >>> Nevertheless, it is true that a site like google may have to deal with millions of >>> mappings while indexing. I do not know how google work for indexing, but I presume >>> that this million of pages are not indexed in one minute by a single machine. >>> Probably that the indexing takes several hours (days?) and is from different machines >>> with load balancers. Probably that the indexing of a site takes at much a few tens of >>> minutes, the ITR could thus limit the TTL to that amount of time. In addition, if >>> load balancers are actually used, one could imagine to use these LB directly as >>> xTRs. >>> >>> Another case where you can observe peaks of destinations is with mails, if your >>> server is attacked and becomes a relay for spams, it can potentially have to >>> contact a huge number of destinations. It is a problem, but I think that the problem >>> is not LISP but the way the server is managed. >>> >>> But you and Jeff are right that LISP has a big problem in case of sort of flash crowds. >>> The question is to know what will die first, the cache or the services that are >>> flash crowded. Such peaks can also be done with DDoS and this is why we are >>> working on techniques to avoid spoofing with LISP. And yes, we have to be >>> honest we do not have the perfect solution now for this problem. >>> >>> Thank you, >>> >>> Damien Saucez >>> >>>> >>>> Many thx, >>>> R. >>> >>> >>> >> > > > From ljakab@ac.upc.edu Mon Jul 18 06:16:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4235321F8B93 for ; Mon, 18 Jul 2011 06:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzJ1LsIqxEpV for ; Mon, 18 Jul 2011 06:16:41 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5363621F8B91 for ; Mon, 18 Jul 2011 06:16:40 -0700 (PDT) Received: from [147.83.34.118] (gambus.ac.upc.es [147.83.34.118]) by gw.ac.upc.edu (Postfix) with ESMTP id 92E1A6B0253; Mon, 18 Jul 2011 15:16:38 +0200 (CEST) Message-ID: <4E243234.3080902@ac.upc.edu> Date: Mon, 18 Jul 2011 15:16:36 +0200 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Damian References: In-Reply-To: OpenPGP: id=90710D74; url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc X-OpenPGP-Fingerprint: 5EBC 8566 7524 D711 F210 9D80 954C 0DEF 9071 0D74 X-Philosophy: "Simplicity is the ultimate sophistication." --Leonardo da Vinci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP basic questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:16:42 -0000 Damian, On 07/18/11 10:59, Damian wrote: > Hi ML, > > I am trying to understand the concept of LISP and would like to pose some > questions, if that is okay. > > Who exactly is supposed to run and configure ETRs and ITRs? In my > understanding it is those organizations, who participate in global BGP > routing, so basically those with their own ASes? What about smaller > organizations who have their own RIPE-registered IP-net but are just one > of many networks in a larger AS? I suppose, it does not make sense for > such smaller organizations to set up their own ETRs/ITRs to serve the > original purpose, as it wouldn't offload the Internet's global BGP table. > > Nevertheless, there are other benefits for smaller companies which run > multiple sites. Site-to-site routing could be balanced for instance, if > each site was multi-homed and multiple ETRs per site were available. I > wonder however, what will happen if someone invests in several Nexus 7000 > to leverage those benefits today, and some time later the AS owning > provider has plans to set up his own LISP-infrastructure. Won't there be a > problem with double-encap or similar? Double-encap was taken into account in the design of LISP, and the scenario you describe will be possible. For the encapsulations on the different levels you can use different mapping systems, so for example on the first level you keep using your company's mapping system and the AS border routers would use the global mapping system. You just have to be careful to avoid MTU problems. Regards, -Lori > Best Regards > Damian > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From luigi@net.t-labs.tu-berlin.de Mon Jul 18 06:16:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4219921F8B9B for ; Mon, 18 Jul 2011 06:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3HInXi6QG6O for ; Mon, 18 Jul 2011 06:16:49 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id BD65D21F8B9F for ; Mon, 18 Jul 2011 06:16:48 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id B9BC070B3885; Mon, 18 Jul 2011 15:16:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luigi Iannone In-Reply-To: <4E242F3C.6060002@raszuk.net> Date: Mon, 18 Jul 2011 15:16:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> <4E242F3C.6060002@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:16:50 -0000 On Jul 18, 2011, at 15:03 , Robert Raszuk wrote: > Hi Damien, >=20 > > So this goes in the direction of Jeff saying that the churn problem > > should not be neglected. >=20 > Very much indeed. >=20 > And to save one more email from Luigi .. I do not buy the argument = that this is simply "out of scope" as this would really mean "out of = practical reality". Too late.. ;-) May be I was unclear. What I wanted to say is that this was out of scope = of the papers that were cited in the thread.=20 I was not saying that such kind of work is "out of scope" in a general = way.=20 Rather the contrary, I truly think that security issues need to be = explored, understood, solved. ciao Luigi >=20 > Cheers, > R. >=20 >=20 >> Hello, > > >> On 18 Jul 2011, at 10:12, Robert Raszuk wrote: >>=20 >>> Hi Damien, >>>=20 >>> Many thx for your reply. >>>=20 >>> Let me clarify ... >>>=20 >>>> I am not sure I understand perfectly what you mean. Why should a = small home >>>> site would have millions of destinations? It would mean that you = observe at least >>>> millions of flows within your small network. >>>=20 >>> Yes. Imagine if you or me announce wiki-leaks-2 content on our = IPv4/IPv6 home web server. I think number of flows will explode. And = imagine we are lucky users of FTTH so no bandwith issue :) >>>=20 >>> Moreover those may not be DOS or spoofing. Those may be legitimate = addresses. And I do not think the server will die. >>>=20 >>> And I am not saying LISP will or will not be able to handle it. I am = just asking how it will handle it ;) Maybe the answer is to in the = moment of exceeding capacity threshold of any xTR push some of the = traffic to few bigger proxies ... just a thought. >>>=20 >>=20 >> Thank you for the clarification, this is a nice example indeed! >>=20 >> You are right that for such legitimate traffic there is problem as it = can be >> assimilated to a flash crowd. In you particular example, I think >> that it is the Map-Resolver or the control plane itself that will = cause the >> problems! >>=20 >> If we consider the cache size it should be ok. If we have >> one million client *simultaneously* and that the system is stupid and >> stores the mapping records as-is, that all the requesters are IPv4 = and >> have two rlocs, then 40MB of storage is required. It is especially = what >> the small home routers have today, but it is not 1million times more >> than the memory they provide now, so it would not be too hard. >>=20 >> But the control-plane in these routers would suffer and these boxes >> are in general pure software and have slow processors so I don't know >> if they will enjoy to update the cache at a rate higher than a few = hundreds >> entries per second. To be honest I don't know what could be achieved = by >> such devices. And even if they are able to deal with this speed, it = will maybe >> be complicated for the boxes to find a MR that will not rate limit = the number >> of requests. >>=20 >> So this goes in the direction of Jeff saying that the churn problem = should >> not be neglected. >>=20 >> Thank you, >>=20 >> Damien Saucez >>=20 >>> Cheers, >>> R. >>>=20 >>>=20 >>>=20 >>> Even in campus networks like our >>>> university we do not observe millions of concurrent flows. In one = day we have in >>>> general 3 million different IP addresses in our network and there = is no mechanism >>>> to limit the traffic but more interestingly, during 5 minute = periods, we observe >>>> peaks at around 60K to 70K concurrent destination addresses and = peaks to 1.2M >>>> L3 flows and interestingly, from 5min time slots to 5min time >>>> slots, we can see big variations (having 60K destination then 20K = then >>>> 40K ... is common) maning that actually the ground traffic that = would stay in the >>>> cache for what ever TTL is not so important. Indeed, a top few (~ = thousands) >>>> destinations are contacted all the time, while the rest could be = seen as noise >>>> with short period of time (from a few seconds to a few hours). So a = good cache >>>> eviction algorithm should solve most of the case. Regarding the = cache size, I >>>> think that the mistake is in the specs, where it is recommended to = have a TTL >>>> of one day. =46rom the temporal locality of Internet traffic, we = can say that this >>>> choice is meaningless. xTR should be able to fix themselves the TTL = of the >>>> mappings they install in their cache (TTL_cache<=3D TTL_Map-Reply). >>>>=20 >>>> Nevertheless, it is true that a site like google may have to deal = with millions of >>>> mappings while indexing. I do not know how google work for = indexing, but I presume >>>> that this million of pages are not indexed in one minute by a = single machine. >>>> Probably that the indexing takes several hours (days?) and is from = different machines >>>> with load balancers. Probably that the indexing of a site takes at = much a few tens of >>>> minutes, the ITR could thus limit the TTL to that amount of time. = In addition, if >>>> load balancers are actually used, one could imagine to use these LB = directly as >>>> xTRs. >>>>=20 >>>> Another case where you can observe peaks of destinations is with = mails, if your >>>> server is attacked and becomes a relay for spams, it can = potentially have to >>>> contact a huge number of destinations. It is a problem, but I think = that the problem >>>> is not LISP but the way the server is managed. >>>>=20 >>>> But you and Jeff are right that LISP has a big problem in case of = sort of flash crowds. >>>> The question is to know what will die first, the cache or the = services that are >>>> flash crowded. Such peaks can also be done with DDoS and this is = why we are >>>> working on techniques to avoid spoofing with LISP. And yes, we have = to be >>>> honest we do not have the perfect solution now for this problem. >>>>=20 >>>> Thank you, >>>>=20 >>>> Damien Saucez >>>>=20 >>>>>=20 >>>>> Many thx, >>>>> R. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From robert@raszuk.net Mon Jul 18 06:20:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6111F21F8BA0 for ; Mon, 18 Jul 2011 06:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=-2.923, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOMpmeHLbjnL for ; Mon, 18 Jul 2011 06:20:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D176821F8B9B for ; Mon, 18 Jul 2011 06:20:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG4yJE6rRDoI/2dsb2JhbABUp3R3iHyjeZ11hjwEkmaFAYtW X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="scan'208";a="3938424" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2011 13:20:57 +0000 Received: from [192.168.1.51] (ams-raszuk-2-87113.cisco.com [10.55.99.78]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6IDKtl5023677; Mon, 18 Jul 2011 13:20:55 GMT Message-ID: <4E243336.90402@raszuk.net> Date: Mon, 18 Jul 2011 15:20:54 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Luigi Iannone References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> <4E242F3C.6060002@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:20:58 -0000 Hi Luigi, >>> So this goes in the direction of Jeff saying that the churn >>> problem should not be neglected. >> >> Very much indeed. >> >> And to save one more email from Luigi .. I do not buy the argument >> that this is simply "out of scope" as this would really mean "out >> of practical reality". > > Too late.. ;-) ;-) > May be I was unclear. What I wanted to say is that this was out of > scope of the papers that were cited in the thread. Ahh ok - it was not clear. Of course it makes sense to divide the work into chunks. > I truly think that security issues need to be explored, understood, > solved. But for me this is not really a security issue, but scaling issue of possible production legitimate use rather then any form of attack. Cheers, r. From damien.saucez@uclouvain.be Mon Jul 18 06:34:06 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6721F8BC1 for ; Mon, 18 Jul 2011 06:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IEF6YAWqbcm for ; Mon, 18 Jul 2011 06:33:58 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id BD4D121F8B64 for ; Mon, 18 Jul 2011 06:33:57 -0700 (PDT) Received: from sleipnier.dhcp.info.ucl.ac.be (sleipnier.dhcp.info.ucl.ac.be [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5789A1C550F; Mon, 18 Jul 2011 15:33:53 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 5789A1C550F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310996033; bh=v36HU7ONIoQLgTxN/KvlWmW9mY+EHNnv0K5RIOZEyoM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f+vJJk6mg18uBMzLI4k+GdesHSl9+9y0hNbpJe8EMYa1xgXoK+Uu/Rh9QSqusZCi8 eRJw5S+KDLTddN04o8l+IK2Czv+LCuPMmUq2WpIJnJaVLGSjiSUvmngRRF1MQ/ocCf eZG2veHYwPhpr/doaEvi22wY6NE010TrfDyCVjg0= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4E242F3C.6060002@raszuk.net> Date: Mon, 18 Jul 2011 15:33:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CBEAD3A-9CB8-4283-BDF2-AC0941AFAF09@uclouvain.be> References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> <4E242F3C.6060002@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5789A1C550F.A2551 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:34:06 -0000 On 18 Jul 2011, at 15:03, Robert Raszuk wrote: > Hi Damien, >=20 > > So this goes in the direction of Jeff saying that the churn problem > > should not be neglected. >=20 > Very much indeed. >=20 > And to save one more email from Luigi .. I do not buy the argument = that this is simply "out of scope" as this would really mean "out of = practical reality". >=20 Definitely, the scalability problem is a major issue in LISP if we do = not do the things correctly. The first part of the scalability work was to = see if LISP data-plane could work in the current situation (cache papers). The second part was to see if the control-plane (mapping system) could work in such situation (we started with LISP-Tree and are still working to = see how to ensure the control-plane scalability). As it seems that LISP could = work in the current Internet (with the assumption we made), we have to = explore the potential new deployment cases of LISP (i.e., corse vs fine grained mapping decomposition, where to put the xTRs...). Then for the = deployments, see how to model the traffic to check if data-plane and control-plane = can resist. And finally consider that malicious people could attack LISP = itself to success attacks. We are still evaluating how to have "new LISP=20 deployment pattern" and have started to lisp the intrinsic security = flows in LISP. So we will eventually be able to see how LISP would react to new deployments with the presence of LISP based security threats. We are still far from being able to answer, but at least we show that under = certain given assumptions LISP could be used and work. With baby steps we are going to more complex cases, but I prefer to have a system that works = but must be optimized that an optimal system that does not work. So definitely scalability and security are key points for LISP. Thank you, Damien Saucez > Cheers, > R. >=20 >=20 >> Hello, > > >> On 18 Jul 2011, at 10:12, Robert Raszuk wrote: >>=20 >>> Hi Damien, >>>=20 >>> Many thx for your reply. >>>=20 >>> Let me clarify ... >>>=20 >>>> I am not sure I understand perfectly what you mean. Why should a = small home >>>> site would have millions of destinations? It would mean that you = observe at least >>>> millions of flows within your small network. >>>=20 >>> Yes. Imagine if you or me announce wiki-leaks-2 content on our = IPv4/IPv6 home web server. I think number of flows will explode. And = imagine we are lucky users of FTTH so no bandwith issue :) >>>=20 >>> Moreover those may not be DOS or spoofing. Those may be legitimate = addresses. And I do not think the server will die. >>>=20 >>> And I am not saying LISP will or will not be able to handle it. I am = just asking how it will handle it ;) Maybe the answer is to in the = moment of exceeding capacity threshold of any xTR push some of the = traffic to few bigger proxies ... just a thought. >>>=20 >>=20 >> Thank you for the clarification, this is a nice example indeed! >>=20 >> You are right that for such legitimate traffic there is problem as it = can be >> assimilated to a flash crowd. In you particular example, I think >> that it is the Map-Resolver or the control plane itself that will = cause the >> problems! >>=20 >> If we consider the cache size it should be ok. If we have >> one million client *simultaneously* and that the system is stupid and >> stores the mapping records as-is, that all the requesters are IPv4 = and >> have two rlocs, then 40MB of storage is required. It is especially = what >> the small home routers have today, but it is not 1million times more >> than the memory they provide now, so it would not be too hard. >>=20 >> But the control-plane in these routers would suffer and these boxes >> are in general pure software and have slow processors so I don't know >> if they will enjoy to update the cache at a rate higher than a few = hundreds >> entries per second. To be honest I don't know what could be achieved = by >> such devices. And even if they are able to deal with this speed, it = will maybe >> be complicated for the boxes to find a MR that will not rate limit = the number >> of requests. >>=20 >> So this goes in the direction of Jeff saying that the churn problem = should >> not be neglected. >>=20 >> Thank you, >>=20 >> Damien Saucez >>=20 >>> Cheers, >>> R. >>>=20 >>>=20 >>>=20 >>> Even in campus networks like our >>>> university we do not observe millions of concurrent flows. In one = day we have in >>>> general 3 million different IP addresses in our network and there = is no mechanism >>>> to limit the traffic but more interestingly, during 5 minute = periods, we observe >>>> peaks at around 60K to 70K concurrent destination addresses and = peaks to 1.2M >>>> L3 flows and interestingly, from 5min time slots to 5min time >>>> slots, we can see big variations (having 60K destination then 20K = then >>>> 40K ... is common) maning that actually the ground traffic that = would stay in the >>>> cache for what ever TTL is not so important. Indeed, a top few (~ = thousands) >>>> destinations are contacted all the time, while the rest could be = seen as noise >>>> with short period of time (from a few seconds to a few hours). So a = good cache >>>> eviction algorithm should solve most of the case. Regarding the = cache size, I >>>> think that the mistake is in the specs, where it is recommended to = have a TTL >>>> of one day. =46rom the temporal locality of Internet traffic, we = can say that this >>>> choice is meaningless. xTR should be able to fix themselves the TTL = of the >>>> mappings they install in their cache (TTL_cache<=3D TTL_Map-Reply). >>>>=20 >>>> Nevertheless, it is true that a site like google may have to deal = with millions of >>>> mappings while indexing. I do not know how google work for = indexing, but I presume >>>> that this million of pages are not indexed in one minute by a = single machine. >>>> Probably that the indexing takes several hours (days?) and is from = different machines >>>> with load balancers. Probably that the indexing of a site takes at = much a few tens of >>>> minutes, the ITR could thus limit the TTL to that amount of time. = In addition, if >>>> load balancers are actually used, one could imagine to use these LB = directly as >>>> xTRs. >>>>=20 >>>> Another case where you can observe peaks of destinations is with = mails, if your >>>> server is attacked and becomes a relay for spams, it can = potentially have to >>>> contact a huge number of destinations. It is a problem, but I think = that the problem >>>> is not LISP but the way the server is managed. >>>>=20 >>>> But you and Jeff are right that LISP has a big problem in case of = sort of flash crowds. >>>> The question is to know what will die first, the cache or the = services that are >>>> flash crowded. Such peaks can also be done with DDoS and this is = why we are >>>> working on techniques to avoid spoofing with LISP. And yes, we have = to be >>>> honest we do not have the perfect solution now for this problem. >>>>=20 >>>> Thank you, >>>>=20 >>>> Damien Saucez >>>>=20 >>>>>=20 >>>>> Many thx, >>>>> R. >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 From damien.saucez@uclouvain.be Mon Jul 18 06:36:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC6421F8563 for ; Mon, 18 Jul 2011 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5xlslzURKKo for ; Mon, 18 Jul 2011 06:36:25 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id EBC7B21F8559 for ; Mon, 18 Jul 2011 06:36:24 -0700 (PDT) Received: from sleipnier.dhcp.info.ucl.ac.be (sleipnier.dhcp.info.ucl.ac.be [130.104.228.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 0DBE61C52AC; Mon, 18 Jul 2011 15:36:21 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 0DBE61C52AC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1310996181; bh=3FP+b6ndz89A3H6gzL7eKpuhUUqT9A8OCVaZFIiRksg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s3S0j+apnTZplcEz1v2jwxdxLWUZaSHlfwVifwMO5YDD8XM0k1OqZsYPm4bTqgdr6 65AVBxdE2BwQaOp6Z471VaQyQELHLsLrNaOa4RoEyYqzVnomBVttTYvOeVg4sfyccN B+bZ6Zrk0htOuWwZBiApv2gKKAYjhdfKC0M1TQis= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <4E243336.90402@raszuk.net> Date: Mon, 18 Jul 2011 15:36:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> <006DBFF7-9682-4EAC-9284-B2BBD0A17254@uclouvain.be> <4E242F3C.6060002@raszuk.net> <4E243336.90402@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 0DBE61C52AC.A80F7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:36:25 -0000 Robert, On 18 Jul 2011, at 15:20, Robert Raszuk wrote: > Hi Luigi, >=20 >>>> So this goes in the direction of Jeff saying that the churn >>>> problem should not be neglected. >>>=20 >>> Very much indeed. >>>=20 >>> And to save one more email from Luigi .. I do not buy the argument >>> that this is simply "out of scope" as this would really mean "out >>> of practical reality". >>=20 >> Too late.. ;-) >=20 > ;-) >=20 >> May be I was unclear. What I wanted to say is that this was out of >> scope of the papers that were cited in the thread. >=20 > Ahh ok - it was not clear. Of course it makes sense to divide the work = into chunks. >=20 >> I truly think that security issues need to be explored, understood, > > solved. >=20 > But for me this is not really a security issue, but scaling issue of = possible production legitimate use rather then any form of attack. >=20 definitely, this was our very first answer to Jeff when he raised us the = problem. Jeff said "DoS", we said "cache management". And your example is perfect to = show this where legitimate traffic has the same effect than an attack. Thx, Damien Saucez > Cheers, > r. >=20 >=20 >=20 >=20 From jnc@mercury.lcs.mit.edu Mon Jul 18 09:00:23 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522B821F8C62 for ; Mon, 18 Jul 2011 09:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl7ZcP5dzvMU for ; Mon, 18 Jul 2011 09:00:22 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id C900221F8C52 for ; Mon, 18 Jul 2011 09:00:22 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 817F518C19F; Mon, 18 Jul 2011 12:00:22 -0400 (EDT) To: damian.lukowski@rwth-aachen.de, lisp@ietf.org Message-Id: <20110718160022.817F518C19F@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 12:00:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] LISP basic questions X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:00:23 -0000 > From: Damian > Who exactly is supposed to run and configure ETRs and ITRs? In my > understanding it is those organizations, who participate in global > BGP routing, so basically those with their own ASes? No; it is intended that any entity (no matter how small) which can benefit from LISP's capabilities can/should run LISP. Those capabilities are many and varied - 'separation of location and identity' is a very basic architectural tool which will inevitably wind up being used in all sorts of ways, including many we do not now see (in line with my favourite aphorism about 'the sign of great architecture is not how well it does the things it was designed to do, but how well it does things you never imagined it would be used for'). So it might be anything as small as a single user who wants to be multi-homed. > I suppose, it does not make sense for such smaller organizations to > set up their own ETRs/ITRs to serve the original purpose, as it > wouldn't offload the Internet's global BGP table. The question of 'helping the routing' is a complicated one - one I don't propose to examine in detail here. Although allowing for much smaller routing tables (by advertising only RLOCs in the backbone, and not LEIDs) was something that was discussed extensively early on (several years back), after thinking about it for a while, it only becomes really plausible at high deployment levels. (That is why the initial driver for LISP deployment is likely to be other capabilities, e.g the traffic engineering stuff.) It's unclear at _initial_ deployment levels how much it will help the routing in the DFZ. There may be _some_ help in the early stages - e.g. DFZ entries intended to support traffic engineering, multi-homing etc can be withdrawn once sites using them transit to LISP, provided there are enough PITRs scattered around the network to make it feasible to depend on LISP for those sites to communicate well with 'legacy' sites (which will, in the initial stages, be the majority of the network). > Nevertheless, there are other benefits for smaller companies which > run multiple sites. Those are definitely one class of users which can benefit immediately. Noel From jnc@mercury.lcs.mit.edu Mon Jul 18 09:15:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B511221F854A for ; Mon, 18 Jul 2011 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyMKIkKMDria for ; Mon, 18 Jul 2011 09:15:15 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3956E21F8531 for ; Mon, 18 Jul 2011 09:15:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A291018C0BB; Mon, 18 Jul 2011 12:15:14 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110718161514.A291018C0BB@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 12:15:14 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:15:15 -0000 > From: Jeff Wheeler > You forget that a feature of LISP is to make multi-homing SOHO sites > cheaper and easier, therefore increasing their number dramatically. > ... > To assume the number of multi-homed end-sites won't grow by 10x is > foolish. I believe we would see more than 100x growth, but even 10x, > plus the cache problems identified, make LISP very much impractical > for content providers. Let me make sure I understand your point here. You don't seem to be disagreeing with the assertion that for most sites (even things like very large universities, etc), their 'working set' (of nodes they communicate) with will be much smaller than the network as a whole? (This makes sense because, as the Internet has grown, the amount of content in various languages has grown, and Spanish-speakers will only be looking at content in Spanish, Mandarin speakers at Mandarin content, etc, etc, naturally leading to the Internet being semi-divided into user communities which are much smaller than the Internet as a whole. The data-driven simulations show exactly this effect.) So only the very largest content providers (YouTube, etc) will have 'working sets' which include a fairly large share of the entire Internet? I have previously commented that such sites have lots of specialized infrastructure to handle their traffic loads - do you think it will be infeasible for them to have specialized LISP infrastructure too? (Leaving aside for a moment what that infrastruture would look like - it's not necessarily separate hardware, it might be integrated into existing boxes on the periphery of their site.) As to the cache problems, let me discuss them in a separate message (to avoid mixing the two issues). Noel From jsw@inconcepts.biz Mon Jul 18 11:30:34 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9121F8AED for ; Mon, 18 Jul 2011 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTPYmhzZOdW3 for ; Mon, 18 Jul 2011 11:30:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6121F8B63 for ; Mon, 18 Jul 2011 11:30:33 -0700 (PDT) Received: by vxi40 with SMTP id 40so3283830vxi.31 for ; Mon, 18 Jul 2011 11:30:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.47 with SMTP id r15mr6493058vdf.110.1311013832852; Mon, 18 Jul 2011 11:30:32 -0700 (PDT) Received: by 10.220.194.7 with HTTP; Mon, 18 Jul 2011 11:30:32 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: <20110718161514.A291018C0BB@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 14:30:32 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:30:34 -0000 Oops, posted to wrong list! ---------- Forwarded message ---------- From: Jeff Wheeler Date: Mon, Jul 18, 2011 at 2:29 PM Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) To: nanog@nanog.org On Mon, Jul 18, 2011 at 12:15 PM, Noel Chiappa wr= ote: > Let me make sure I understand your point here. You don't seem to be > disagreeing with the assertion that for most sites (even things like very > large universities, etc), their 'working set' (of nodes they communicate) > with will be much smaller than the network as a whole? Why would you assume this to be true if LISP also promises to make multi-homing end-sites cheaper and easier, and independent of the ISP's willingness to provide BGP without extra cost? =A0You see, if every SOHO network and "power user" can suddenly become multi-homed without spending a great deal of money on a powerful router and ISP services which support BGP, many of these networks will do so. The working sets of a scaled-up, LISP future will make the BGP DFZ of today look small. > So only the very largest content providers (YouTube, etc) will have > 'working sets' which include a fairly large share of the entire Internet? No, any end-site of interest to a DoS attacker must be able to deal with a working set which includes the entire Internet. =A0The reason for this is obvious: it will be the best way to attack a LISP infrastructure, and it will not be difficult for attackers to send packets where each packet's source address appears to be from a different mapping system entry. Some people have commented that LISP hopes to prevent source address spoofing through technical means that have not been fully explored. This is a good goal but it must require the ETR doing address validation to look-up state from the mapping system. =A0It will have the same cache churn problem as an ITR subject to a reflection attack (or an outbound DoS flow meant to disable that ITR.) So there is no practical means of doing source address validation on ETRs (under DoS.) =A0Even if you did that, the ITR must still be subject to the occasional large flow of outbound traffic from a compromised host (dorm machine, open wireless, hacked server, etc.) which is intended to disable the ITR. > I have previously commented that such sites have lots of specialized > infrastructure to handle their traffic loads - do you think it will be > infeasible for them to have specialized LISP infrastructure too? (Leaving > aside for a moment what that infrastruture would look like - it's not > necessarily separate hardware, it might be integrated into existing boxes > on the periphery of their site.) Again, every content shop will need to have that specialized infrastructure. =A0Every site that someone might have a motive to launch a DoS attack against must be able to withstand at least trivial DoS. If you think only the super-huge sites will have a large working set, you are again ignoring DoS attacks. The same is true of ISP subscriber access platforms. =A0If my ISP's BRAS effectively goes down regularly, I won't keep that ISP service very long, I'll change to a competitor. =A0The more subscribers on one BRAS, the more likely it will receive frequent DoS attacks. So in reality, the common cache size needed to achieve a high hit rate really does not matter, unless you wish to ignore DoS (which you seem to want to do very badly.) -- Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jnc@mercury.lcs.mit.edu Mon Jul 18 12:21:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6ED21F8A4E for ; Mon, 18 Jul 2011 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z7RMPcEKQDO for ; Mon, 18 Jul 2011 12:21:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id C327D21F8A1A for ; Mon, 18 Jul 2011 12:21:46 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2E8B818C1A3; Mon, 18 Jul 2011 15:21:45 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110718192145.2E8B818C1A3@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 15:21:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:21:48 -0000 > From: Jeff Wheeler >> the assertion that for most sites (even things like very large >> universities, etc), their 'working set' (of nodes they communicate >> [with]) .. will be much smaller than the network as a whole? > Why would you assume this to be true if LISP also promises to make > multi-homing end-sites cheaper and easier, and independent of the ISP's > willingness to provide BGP without extra cost? Please read carefully what I wrote. To start with, why will multi-homing of more sites elsewhere on the network increase the number of nodes the _average_ site communicates with (i.e. increase the sites of that site's 'working set')? The former is purely a technical issue of how things are wired underneath (where the users cannot see them); the latter is driven by users access patterns. There is no connection between the two that I can see? Having answered that, where is the problem with my statement? Actual packet traces from several large sites show it to be true in those traces. Do you have any data which shows otherwise (for many/most sites)? > You see, if every SOHO network and "power user" can suddenly become > multi-homed without spending a great deal of money on a powerful router > and ISP services which support BGP, many of these networks will do so. Yes. And? > unless you wish to ignore DoS (which you seem to want to do very badly.) Where did I say that? Please don't put words I not only never said, but have no intention of saying, in my mouth. Noel From jnc@mercury.lcs.mit.edu Mon Jul 18 13:07:39 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4C221F8599 for ; Mon, 18 Jul 2011 13:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C79bodVCX0CY for ; Mon, 18 Jul 2011 13:07:38 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFCB21F85A3 for ; Mon, 18 Jul 2011 13:07:38 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 086E218C1A4; Mon, 18 Jul 2011 16:07:38 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110718200738.086E218C1A4@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 16:07:38 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:07:39 -0000 > From: Jeff Wheeler > any subscriber access platform, must be able to deal with the threat > of DoS attacks. I definitely agree with this, and I've been pondering it a bit over the last couple of days. (BTW, do you forsee this being an issue for IPv4 and IPv6, or 'mostly' an IPv6 issue, because of the very large address space?) Anyway, thinking about this 'DoS using packets with source-addresses scattered throughout the address space' issue, and trying to thoroughly characterize the issue, there seem to me at a high level to be two, maybe three, ways this can be a problem for LISP (other than the sheer number of packets, which is already an issue even in non-LISP configurations). The first is problems with the cache (primarily through valid and useful entries being displaced by 'useless' entries, although I suppose if one has a cache which tries to retain all the mappings one can see, the growth in the cache could also be a problem), the second is the volume of control traffic, and the third is the volume of 'no-match' traffic (i.e. packets sent out from the site to an ITR for which the ITR does not have a mapping) - depending of course on how the ITR handles such packets (if it simply drops such packets, that's not a big problem.) Did I miss one (at this level)? To analyze the problems with the cache a little deeper, there are two parts to the problem: negative cache entries (i.e. entries which say 'there is no mapping for this range of the space') and positive entries which are not 'real' (as in, for places this site would normally communicate with, which serve only to expand the size of the working set). The former can be handled by limiting the cache size, and preferentially discarding and/or not installing 'negative' entries when the cache is large (i.e. under DoS attack). (This could cause a problem in the next stage - control traffic - though, but I will talk about that later on.) Non-'real' positive entries are somewhat harder to deal with, but there seem to be some fairly simple strategies which can ameliorate the attack. For example, one would be to segment the cache into two portions, the 'main' cache and a 'rabbit garden' cache. Entries would only be promoted from the second to the first after being used more than N times (where N is a small integer, e.g. '2'). On a full cache, and needing to evict an older entry to make room for a new one, the new cache entry would only turf entries from the 'rabbit garden' section. (Entries in the 'main' cache would only be removed on timeout.) Clearly, a DoS attack will only thrash the 'rabbit garden' portion of the cache, leaving the main cache unaffected. The only difficulty comes when there is an attempt to communicate with a new legitimate destination; the cache entry for that may get evicted before it can be promoted to the 'main' cache. Unless the DoS attack is running quickly enough to flush the entire 'rabbit garden' in less than one RTT for the new destination (after which a second packet to that destination will promote the entry to the 'main' cache), it should make it through. If not... actually, now that I think about it, I have come at this from the wrong end, because if one has the control traffic rate limited (as I think one must, see below), _iff_ one can protect legitimate control requests (and I think one might be able to - see below), then you can pretty much guarantee that the legitimate mapping will be around long enough to be promoted. The obvious approach on the control traffic, to prevent a flood of incoming DoS traffic from creating a flood of control traffic, is to rate limit it (e.g. increment a counter every time a mapping request is sent, and once the counter has reached M, where M would be say 1,000, send no further mapping requests - the counter is cleared once every second). (In fact, I think there might already be a rate limitation on the generation of mapping requests?) This will likely have a negative effect on real traffic from the site, though, although I can imagine a variety of heuristics to try and select out 'real' traffic, and treat it preferentially. E.g. once the rate limit has been reached, examine the packet, and if it is a TCP SYN (and not a SYN-ACK) ignore the rate-limit - this is an outgoing TCP connection request, and should be OK. Incoming real requests would still get drowned, but for many sites, which are primarily consumers, and not providers, this would perhaps be adequate. To protect incoming requests... hmmm, I'd want to go look and see how large servers protect themselves now, see if there's something there that can be copied. Alternatively, one could, in the cache managment (above) retain negative cache entries which are 'large', and use them to reduce the control traffic that way (since each 'large' negative cache entry will soak up a chunk of the DoS traffic). At another level, one can take advantage of the fact that one has to 'bounce' traffic off a machine inside the site to attack the ITR mapping mechanisms; if one can 'harden' the host against such attacks, then you can kill the problem that way. I dunno, I'm not sure that this is an insoluble problem - _if_ one puts ones mind to solving it. I agree that it is an important issue, though. Noel From jmh@joelhalpern.com Mon Jul 18 13:22:03 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F721F85C6 for ; Mon, 18 Jul 2011 13:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AusUEFp9iKyR for ; Mon, 18 Jul 2011 13:22:03 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 466E321F85A7 for ; Mon, 18 Jul 2011 13:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 52276325C157; Mon, 18 Jul 2011 13:22:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-2.clppva.btas.verizon.net [71.161.50.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id BD1DE3228384; Mon, 18 Jul 2011 13:22:00 -0700 (PDT) Message-ID: <4E2495E0.4000304@joelhalpern.com> Date: Mon, 18 Jul 2011 16:21:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: jsw@inconcepts.biz References: <20110718200738.086E218C1A4@mercury.lcs.mit.edu> In-Reply-To: <20110718200738.086E218C1A4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:22:03 -0000 I may be missing something. Maybe something imp0ortant. But pretneding for the moment that I understand this discussion... Fundamentally, if a subscriber DoS' himself, and denies himself service, then he hurts himself. So? Now, there do need to be ways that this is prevented from hurting the rest of the system. But there are already specified rate limits. Even for an enterprise, if a device within the enterprise DoS' the enterprise, then the enterprise has to deal with it. One may want additional protections, but they are largely a local, implementation, matter. There is one case that is, I think, important, but fairly easily dealt with. There are Proxy ITRs in the system. Those end up accepting traffic from wide ranges of soruces for wide ranges of destinations (depending upon which PITR deployment model you find useful.) Those would seem to be vulnerable to DoS. However, those are few, far between, and could reasoanbly be specialized boxes. If they participate in the ALT, for example, they presumably can finess a number of the implications of scatter attacks via clever implementation. Yours, Joel On 7/18/2011 4:07 PM, Noel Chiappa wrote: > > From: Jeff Wheeler > > > any subscriber access platform, must be able to deal with the threat > > of DoS attacks. > > I definitely agree with this, and I've been pondering it a bit over the > last couple of days. (BTW, do you forsee this being an issue for IPv4 and > IPv6, or 'mostly' an IPv6 issue, because of the very large address space?) From jnc@mercury.lcs.mit.edu Mon Jul 18 13:36:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E860421F8B01 for ; Mon, 18 Jul 2011 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWuD1XBT4iSQ for ; Mon, 18 Jul 2011 13:36:41 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8755B21F8B00 for ; Mon, 18 Jul 2011 13:36:41 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1A0B618C1A4; Mon, 18 Jul 2011 16:36:41 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110718203641.1A0B618C1A4@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 16:36:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:36:43 -0000 > From: "Joel M. Halpern" > Fundamentally, if a subscriber DoS' himself, and denies himself > service, then he hurts himself. So? The issue is that someone _outside_ can mount a DoS attack by 'bouncing' traffic off a machine inside the site - e.g. by sending a zillion TCP SYN requests, from random (bogus) source addresses. Jeff also raised the possibility of a breakin inside the site (either by breaking into a machine, or breaking into a wireless network, etc, etc.) On another (unrelated to your question) note: I think it's worth spending a few cycles on this to work out if the solution(s) are purely implementation (e.g. two-stage caches, or whatever), or if there are any protocol changes needed. If it's just the former, it can clearly be put off 'until needed'. Noel From jmh@joelhalpern.com Mon Jul 18 13:50:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B825B21F876F for ; Mon, 18 Jul 2011 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 716LOmct0m4R for ; Mon, 18 Jul 2011 13:50:45 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7A321F8764 for ; Mon, 18 Jul 2011 13:50:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7450D325C157 for ; Mon, 18 Jul 2011 13:50:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-2.clppva.btas.verizon.net [71.161.50.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 08BAD32460AF for ; Mon, 18 Jul 2011 13:50:43 -0700 (PDT) Message-ID: <4E249C9D.50203@joelhalpern.com> Date: Mon, 18 Jul 2011 16:50:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: lisp@ietf.org References: <20110718203641.1A0B618C1A4@mercury.lcs.mit.edu> In-Reply-To: <20110718203641.1A0B618C1A4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:50:45 -0000 Okay, a reflective attack has some relevance, at least for enterprise. (For residential, the number of things one has to assume before this becomes an issue is simply too large for me to get.) Yes, this probably does take some additional cleverness in implementation. For small enterprise, I can see some ways it works. For large ones, we are into the problem of how to build a front-ending device that needs state to respond to DoS attacks, but it has to not fall over before the target of the DoS. given that some large content providers are looking at this, I would be interested to see what paths they see as worth investigating. Yours, Joel On 7/18/2011 4:36 PM, Noel Chiappa wrote: > > From: "Joel M. Halpern" > > > Fundamentally, if a subscriber DoS' himself, and denies himself > > service, then he hurts himself. So? > > The issue is that someone _outside_ can mount a DoS attack by 'bouncing' > traffic off a machine inside the site - e.g. by sending a zillion TCP SYN > requests, from random (bogus) source addresses. Jeff also raised the > possibility of a breakin inside the site (either by breaking into a > machine, or breaking into a wireless network, etc, etc.) > > > On another (unrelated to your question) note: I think it's worth spending a > few cycles on this to work out if the solution(s) are purely implementation > (e.g. two-stage caches, or whatever), or if there are any protocol changes > needed. If it's just the former, it can clearly be put off 'until needed'. > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jsw@inconcepts.biz Mon Jul 18 14:13:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537921F881C for ; Mon, 18 Jul 2011 14:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Da-uvVG6Gg for ; Mon, 18 Jul 2011 14:13:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 517F921F8785 for ; Mon, 18 Jul 2011 14:13:28 -0700 (PDT) Received: by vxi40 with SMTP id 40so3402924vxi.31 for ; Mon, 18 Jul 2011 14:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.8 with SMTP id v8mr1721584vch.219.1311023607544; Mon, 18 Jul 2011 14:13:27 -0700 (PDT) Received: by 10.220.194.7 with HTTP; Mon, 18 Jul 2011 14:13:27 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <20110718192145.2E8B818C1A3@mercury.lcs.mit.edu> References: <20110718192145.2E8B818C1A3@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 17:13:27 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:13:29 -0000 On Mon, Jul 18, 2011 at 3:21 PM, Noel Chiappa wro= te: > To start with, why will multi-homing of more sites elsewhere on the netwo= rk > increase the number of nodes the _average_ site communicates with Because you will benefit less from aggregation of many users into a single unit of state information -- a CIDR route entry in the DFZ -- the average working set increases. > =A0 =A0> You see, if every SOHO network and "power user" can suddenly bec= ome > =A0 =A0> multi-homed without spending a great deal of money on a powerful= router > =A0 =A0> and ISP services which support BGP, many of these networks will = do so. > > Yes. And? That is what causes the increase in number of end-sites, and as a result, the larger working set. > =A0 =A0> unless you wish to ignore DoS (which you seem to want to do very= badly.) > > Where did I say that? Please don't put words I not only never said, but h= ave > no intention of saying, in my mouth. If you don't want to ignore DoS, then you should concern yourself more with ensuring that it is practical for an xTR to carry all of the possible mappings and not rely on a cache at all. That is what is needed for a targeted xTR to be "DoS proof" to the same degree that common BGP routers are today -- or at least, the xTR must be able to churn its cache at a high enough rate that an attack would saturate the available Internet connection. SOHO CPE, for example, is more appropriately designed this way. On Mon, Jul 18, 2011 at 4:07 PM, Noel Chiappa wro= te: > I definitely agree with this, and I've been pondering it a bit over the > last couple of days. (BTW, do you forsee this being an issue for IPv4 and > IPv6, or 'mostly' an IPv6 issue, because of the very large address space?= ) The problem is worse with IPv6 because of the holes in the address space between active allocations. The larger address space is not, in itself, the cause of the negative cache problem; but the way holes are handled by the MS protocol. For IPv4, the holes are fewer and more easily represented, so it is not conceivable that LISP will require substantially more FIB than the BGP DFZ, even for a worst-case scenario such as a DoS specifically exploiting the negative mappings. You can calculate this if you wish, by building a Trie of the current DFZ and counting all empty node pointers as negative mappings. You'll get a number that is bigger than zero (as if the router did not need a cache) but it won't be 10x bigger like for IPv6. > At another level, one can take advantage of the fact that one has to 'bou= nce' > traffic off a machine inside the site to attack the ITR mapping mechanism= s; if > one can 'harden' the host against such attacks, then you can kill the pro= blem > that way. If you could do this, certainly it would help the ITR for the case of inbound attacks. However, the same problem exists for ETRs if they are going to do any kind of source address validation. I do not know how the LISP community envisions this working, but I am fairly sure it will be affected by the same scaling limitations -- the ETR must be able to look-up entries from the mapping system to validate the source address of packets (even loosely) and thus it will have a churn problem. > I dunno, I'm not sure that this is an insoluble problem - _if_ one puts o= nes > mind to solving it. I agree that it is an important issue, though. It might not be unsolvable. I think the efforts of LISP developers should be focused on this issue, as it is really the only huge, show-stopping issue I see that makes it impractical for Internet-scale use. If this problem can be overcome, LISP has a great potential. I like the concept of LISP more than is apparent from my postings -- but I also live in the practical world where I see > 10Mpps DoS attacks every day. On Mon, Jul 18, 2011 at 4:21 PM, Joel M. Halpern wrot= e: > Fundamentally, if a subscriber DoS' himself, and denies himself service, > then he hurts himself. =A0So? Of course this is true, but imagine that a malicious program is installed on one subscriber's PC behind an ITR that serves ten thousand subscribers (nominal.) You don't want service for all those subscribers to be disrupted because of one infected machine. The same problem is present in mixed-use data-center networks, where there are commonly thousands (at least) of servers self-managed by thousands of different customers. > Now, there do need to be ways that this is prevented from hurting the res= t > of the system. =A0But there are already specified rate limits. I think scaling up the mapping service infrastructure should be very easy. I am truly not worried about that in the least. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jnc@mercury.lcs.mit.edu Mon Jul 18 14:49:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B677421F86FF for ; Mon, 18 Jul 2011 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP7xqFF1TE4J for ; Mon, 18 Jul 2011 14:49:49 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id DE25521F86D9 for ; Mon, 18 Jul 2011 14:49:46 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0F6CD18C1A8; Mon, 18 Jul 2011 17:49:46 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110718214946.0F6CD18C1A8@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 17:49:46 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:49:49 -0000 > From: Jeff Wheeler >> why will multi-homing of more sites elsewhere on the network >> increase the number of nodes the _average_ site communicates with > Because you will benefit less from aggregation of many users into a > single unit of state information -- a CIDR route entry in the DFZ -- > the average working set increases. You seem to be hearing a different question than the one I am asking, because you're giving an answer that talks about mechanisms, state, etc whereas I'm talking about usage patterns (at a high level). Let me try and ask it again, making the wording less susceptible to Why will multi-homing of more sites on the network increase the number of distant sites (whether those sites are multi-homed or not) which the _average_ site communicates with? Note that I am asking about _sites_, not routing entries, mapping entries, or any other low-level mechanistic things. Once we're straight there, we'll work on into lower-level issues like state, etc. Noel From jsw@inconcepts.biz Mon Jul 18 16:38:46 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759C721F8794 for ; Mon, 18 Jul 2011 16:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k90qguct23M6 for ; Mon, 18 Jul 2011 16:38:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D136521F875E for ; Mon, 18 Jul 2011 16:38:45 -0700 (PDT) Received: by vxi40 with SMTP id 40so3480153vxi.31 for ; Mon, 18 Jul 2011 16:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.197 with SMTP id g5mr1777292vcx.254.1311032325191; Mon, 18 Jul 2011 16:38:45 -0700 (PDT) Received: by 10.220.194.7 with HTTP; Mon, 18 Jul 2011 16:38:45 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <20110718214946.0F6CD18C1A8@mercury.lcs.mit.edu> References: <20110718214946.0F6CD18C1A8@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 19:38:45 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:38:46 -0000 On Mon, Jul 18, 2011 at 5:49 PM, Noel Chiappa wro= te: > =A0Why will multi-homing of more sites on the network increase the number > =A0of distant sites (whether those sites are multi-homed or not) which th= e > =A0_average_ site communicates with? > > Note that I am asking about _sites_, not routing entries, mapping entries= , > or any other low-level mechanistic things. Once we're straight there, > we'll work on into lower-level issues like state, etc. Today you may perceive a "site" as an entry in the BGP DFZ, which may encompass several tens of thousands of end-users. When a "site" becomes a SOHO network, a cell tower, a public wireless hot-spot, etc. the average number of end-users per "site" decreases and thus the number of distinct "sites" you are communicating with increases. You can pretend this is a semantic issue all day, but what it boils down to is the number of units of routing state will increase to serve the same number of end-users. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jnc@mercury.lcs.mit.edu Mon Jul 18 17:47:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E089B21F8794 for ; Mon, 18 Jul 2011 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXRXoC4mPhzK for ; Mon, 18 Jul 2011 17:47:54 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A74C621F877B for ; Mon, 18 Jul 2011 17:47:52 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 150C818C1A8; Mon, 18 Jul 2011 20:47:52 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 20:47:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 00:47:55 -0000 > From: Jeff Wheeler > If you don't want to ignore DoS, then you should concern yourself more > with ensuring that it is practical for an xTR to carry all of the > possible mappings and not rely on a cache at all. That is what is > needed for a targeted xTR to be "DoS proof" to the same degree that > common BGP routers are today You've identified a problem (DoS), but why do you insist that the only solution is "for an xTR to carry all of the possible mappings"? That's kind of like saying that gasoline is going to become scaree, therefore all cars should get 2,000 MPG - ignoring alternative solutions like other fuels, etc, etc. As long as the solution _works_, what do you care what the mechanism is? (Incidentally, that approach to handling mappings was considered extensively several years ago - see NERD - and it has problems of its own that led to it being dropped.) > the same problem exists for ETRs if they are going to do any kind of > source address validation. So I can understand this fully, why would they be wanting to do this? > I think the efforts of LISP developers should be focused on this issue > ... If this problem can be overcome, LISP has a great potential. Perhaps you'd be interested in working on this issue, then (especially in light of your first comment immediately below)? I take it from the fact that you didn't comment on most of the earlier material in that message - e.g. my three-part threat area characterization (cache churn, control traffic, missing-mapping user data packets) - that the stuff up until this point was OK? Perhaps that could all be used as the basis for an I-D on the subject? > I like the concept of LISP more than is apparent from my postings -- > but I also live in the practical world where I see 10Mpps DoS attacks > every day. Understood. > it is really the only huge, show-stopping issue I see that makes it > impractical for Internet-scale use. Actually, there is at least one more I can think of... :-) > imagine that a malicious program is installed on one subscriber's PC > behind an ITR that serves ten thousand subscribers (nominal.) You don't > want service for all those subscribers to be disrupted because of one > infected machine. I got an off-line response to an earlier message which suggested that one solution to the 'bounce' attack would be a per-source classifier for the mapping lookup rate-limiter; that way, the source causing all the new cache entries would be slowed down, and nobody else would be affected. I'm not sure how useful that would be for 'bounce' attacks (which could be directed at all of the servers at a site), but it would certainly work well against this particular one (and ones that look like it, like the mixed data-center one you mentioned next). Noel From jnc@mercury.lcs.mit.edu Mon Jul 18 18:28:38 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D5121F877B for ; Mon, 18 Jul 2011 18:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWL79HUIQvXU for ; Mon, 18 Jul 2011 18:28:37 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 86A6021F8753 for ; Mon, 18 Jul 2011 18:28:37 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 10C1D18C1A5; Mon, 18 Jul 2011 21:28:37 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110719012837.10C1D18C1A5@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 21:28:37 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 01:28:38 -0000 > From: Jeff Wheeler >> Why will multi-homing of more sites on the network increase the number >> of distant sites (whether those sites are multi-homed or not) which the >> _average_ site communicates with? > Note that I am asking about _sites_, not routing entries, mapping > entries, or any other low-level mechanistic things. Once we're straight > there, we'll work on into lower-level issues like state, etc. > Today you may perceive a "site" as an entry in the BGP DFZ, which may > encompass several tens of thousands of end-users. Ah, no. I _definitely_ do not perceive a 'site' as anything to do with routing table entries, etc. To me a 'site' is an organization - a company, a university, whatever. How _those_ translate into routing table entries, etc, (both at the moment, and going forward in time - and also into other mechanisms such as mappings) is of course a necessary (but later) stage in any analysis - but I want to be methodical, and start with the first step first. So let's try it this way: Why will multi-homing of more organizations on the network increase the number of distant organizations (whether those are multi-homed or not) which the _average_ organization communicates with? Note that there have historically been developments (e.g. the increase in embedded content on web pages) which _have_ had an effect on "the number of distant organizations ... which the _average_ organization communicates with", so it's not like that _cannot_ change. What I'm after though, is whether _multihoming_ will change it. > When a "site" becomes a SOHO network, a cell tower, a public wireless > hot-spot, etc. the average number of end-users per "site" decreases At least two of those (the cell tower and wireless hot-spot) would be named out of what I think of as RLOC space, and would not influence calculations on the number of mappings, etc at all. > what it boils down to is the number of units of routing state will > increase to serve the same number of end-users. It depends on what you mean by 'routing state'. Do you mean 'forwarding table entries' - or to be more precise, 'things nameable in a forwarding table entry', or 'elements in the global path selection process' (aka 'routes')? At the moment they are the same, but since LISP is trying to break that association, it's necessary to think of them separately. Anyway, if you meant 'elements in the global path selection process' I would definitely disagree. Noel From jsw@inconcepts.biz Mon Jul 18 18:36:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4121F85AA for ; Mon, 18 Jul 2011 18:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fSaAyKVOsai for ; Mon, 18 Jul 2011 18:36:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEC321F84FB for ; Mon, 18 Jul 2011 18:36:28 -0700 (PDT) Received: by vws12 with SMTP id 12so3511714vws.31 for ; Mon, 18 Jul 2011 18:36:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.163 with SMTP id m3mr6815782vdv.244.1311039387494; Mon, 18 Jul 2011 18:36:27 -0700 (PDT) Received: by 10.220.194.7 with HTTP; Mon, 18 Jul 2011 18:36:27 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> References: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 21:36:27 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 01:36:29 -0000 On Mon, Jul 18, 2011 at 8:47 PM, Noel Chiappa wro= te: > You've identified a problem (DoS), but why do you insist that the only > solution is "for an xTR to carry all of the possible mappings"? That's ki= nd of That is the only solution which would have parity with the DoS-tolerance of today's "BGP routers." If you can invent a better means of handling this problem, that will be good news for everyone. But so far, LISP is simply relying on the promise that the cache management mechanisms will be good enough. > =A0 =A0> the same problem exists for ETRs if they are going to do any kin= d of > =A0 =A0> source address validation. > > So I can understand this fully, why would they be wanting to do this? Perhaps I am confused about this, but my understanding is that the LISP community is quite interested in the ability to prevent source address spoofing and does want the ETR to somehow have this capability. It has been suggested, in the past few days in fact, that it would be a tool for preventing the reflection-based ITR DoS I have supposed. However, that is not possible if ETRs aren't able to do this. It is fairly common for carrier networks on today's Internet to run loose uRPF on their IP backbones. It stops them from having to carry useless traffic for which there can be no legitimate response, while still allowing them to bill for that traffic at their customer ingress points. An ETR also can't do this if it is not able to know at least all positive mappings. For it to know all positive mappings, it either must not rely on the cache, or be subject to the negative response attack and resulting churn problems I have outlined. > light of your first comment immediately below)? I take it from the fact t= hat > you didn't comment on most of the earlier material in that message - e.g.= my > three-part threat area characterization (cache churn, control traffic, > missing-mapping user data packets) - that the stuff up until this point w= as > OK? Perhaps that could all be used as the basis for an I-D on the subject= ? I have barely scratched the surface in the area of control traffic / MS infrastructure, etc. I do not see value in even examining these things in detail until there is serious effort to make progress on the problem of DoS-induced cache churn, and a broader understanding of how a dramatic increase in the number of multi-homed SOHO networks will affect the number of cache entries that must be supported by ITRs. If the walls of a building were about to collapse and no one knew yet how to repair them, I would not worry too much about a leaky roof! > =A0 =A0> it is really the only huge, show-stopping issue I see that makes= it > =A0 =A0> impractical for Internet-scale use. > > Actually, there is at least one more I can think of... :-) If you are imagining an excess of signalling traffic within the MS infrastructure (and my understanding in this area is very weak) I believe that is a solvable problem. If you have some other problem in mind, I would be interested in reading about it. > I got an off-line response to an earlier message which suggested that one > solution to the 'bounce' attack would be a per-source classifier for the > mapping lookup rate-limiter; that way, the source causing all the new cac= he > entries would be slowed down, and nobody else would be affected. This is practical to implement in some network designs, and is hard in others. It is a good idea but it doesn't solve the problem that the targeted host can still be disabled with a very small amount of malicious traffic. As I keep mentioning, modern routers can only do around 20k FIB updates per second. So with your per-L2ADJ-MS-punt-policer concept, any host can still be disabled with a DoS attack of < 20k PPS. > I'm not sure how useful that would be for 'bounce' attacks (which could b= e > directed at all of the servers at a site) Indeed. :-/ --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From robert@raszuk.net Tue Jul 19 00:15:29 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2921F8681 for ; Tue, 19 Jul 2011 00:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=-2.598, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suNWt3NitIxc for ; Tue, 19 Jul 2011 00:15:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 34FF621F8677 for ; Tue, 19 Jul 2011 00:15:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAJcuJU6rRDoG/2dsb2JhbABTmEiPAHeIfKVrnk6GPASSZ4UDi1c X-IronPort-AV: E=Sophos;i="4.67,227,1309737600"; d="scan'208";a="4234582" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jul 2011 07:15:24 +0000 Received: from [192.168.1.68] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6J7FMd9013310 for ; Tue, 19 Jul 2011 07:15:23 GMT Message-ID: <4E252F0C.4030402@raszuk.net> Date: Tue, 19 Jul 2011 09:15:24 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: lisp@ietf.org References: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> In-Reply-To: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 07:15:29 -0000 Hi Noel, > I got an off-line response to an earlier message which suggested that one > solution to the 'bounce' attack would be a per-source classifier for the > mapping lookup rate-limiter; that way, the source causing all the new cache > entries would be slowed down, and nobody else would be affected. As already mentioned on this thread I presented the case that such massive bouncing behaviour would not be due to attack, but by legitimate use of the server with some attractive content. I would question if the answer should be in slowing down the data. I would rather see also as already mentioned to fall-back/punt to some more powerful proxies rather then slowing down. And btw I think NERD's idea was not pursued due to issues found. I think ALT was chosen just to get something rolling. IMHO we should really experiment with number of mapping planes not just one. FWIW I like NERD's approach .. well if not to all sites .. maybe to only those which may ever be subject to such data patterns like discussed above. Best regards, R. From pfrejborg@gmail.com Tue Jul 19 00:21:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9218921F855F for ; Tue, 19 Jul 2011 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaxwlDF-PbCh for ; Tue, 19 Jul 2011 00:21:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 267CC21F8550 for ; Tue, 19 Jul 2011 00:21:15 -0700 (PDT) Received: by ewy19 with SMTP id 19so2109523ewy.31 for ; Tue, 19 Jul 2011 00:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oXUfza6YMxwleffgqM87lAPW3PRI+Pymk1mBLUzIzn8=; b=OEagYWEvPkpKuL+toUEqHY+H25OngTGtDI4lv9rFhtqeqHCMG77yjM/3Qi8KhlmKNf XlUVlwobz8M44ZMmw2x7IZLdPld5eo/zzbN5UziNGbfq5o8kTb1ty0Dy/ROerKksQ9WJ lDPBh6WGjg8/JkgM380x4rQ6XOwIadtKm016c= MIME-Version: 1.0 Received: by 10.213.29.65 with SMTP id p1mr365937ebc.12.1311060075157; Tue, 19 Jul 2011 00:21:15 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Tue, 19 Jul 2011 00:21:14 -0700 (PDT) In-Reply-To: References: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Date: Tue, 19 Jul 2011 10:21:14 +0300 Message-ID: From: Patrick Frejborg To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 07:21:20 -0000 On Tue, Jul 19, 2011 at 4:36 AM, Jeff Wheeler wrote: > Perhaps I am confused about this, but my understanding is that the > LISP community is quite interested in the ability to prevent source > address spoofing and does want the ETR to somehow have this > capability. =A0It has been suggested, in the past few days in fact, that > it would be a tool for preventing the reflection-based ITR DoS I have > supposed. =A0However, that is not possible if ETRs aren't able to do > this. > I believe this scenario is a real threat for cache churn, i.e. if the ETR is going to prevent source address spoofing. The hacking culture has recently moved into a new era, see http://www.time.com/time/business/article/0,8599,2079423,00.html The communities do have really large botnets, with millions of "clients". Depending on how the clients are located - worst case is that each client is located at a specific DFZ prefix (which is not likely) - a botnet might perhaps create a cache churn and there is no way the ETR can separate fake traffic from real traffic. The reflective attack at an ITR can be prevented by a rate limiter (as Noel pointed out), by identifying the botnet client by the source address. But what if the botnet client changes randomly source address within the subnet for each request?? Patrick From dino@cisco.com Tue Jul 19 01:13:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4CF21F8788 for ; Tue, 19 Jul 2011 01:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.644 X-Spam-Level: X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=-3.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CVleYsp4uu1 for ; Tue, 19 Jul 2011 01:13:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E29BE21F8754 for ; Tue, 19 Jul 2011 01:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1224; q=dns/txt; s=iport; t=1311063230; x=1312272830; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=qMd2i9KrYuG19ekMpg+qfnxwfWRQtzrK34dBoF/Ealg=; b=hK5OZ6/wzVZtX2QHst02dOouthB2i53pcQXCIUR7XBdw9TVR2dJIMdDg uAmWpOi7TytCpsRJcUSqCd/oq1vuKw2ZTAQkfOiebSYXElyZcyow+BbuP OaRwiZLkrwI7ay0APVdo+UaSxVZ78ijvgJoLtV/0+mljTxuL3p7MjBxVB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAPY7JU6rRDoH/2dsb2JhbABTmEiPAHeIfKV1nk2FXV8Eh1SLE4UDi3U X-IronPort-AV: E=Sophos;i="4.67,227,1309737600"; d="scan'208";a="4246466" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jul 2011 08:13:49 +0000 Received: from [192.168.1.6] (sjc-vpn5-692.cisco.com [10.21.90.180]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6J8Dm6D024556; Tue, 19 Jul 2011 08:13:48 GMT Message-Id: <7097D47C-914B-438A-A392-0DDB6CFDE7B0@cisco.com> From: Dino Farinacci To: robert@raszuk.net In-Reply-To: <4E23EAFB.3080604@raszuk.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 19 Jul 2011 01:13:48 -0700 References: <7AE018F5-5170-473D-8C01-D52EB4DA9238@cisco.com> <7A2A68BC-E5E6-4560-9213-8CFF39F7267E@cisco.com> <710E84E4-C6CB-4FA8-AB88-F12055B4C0D3@uclouvain.be> <0B6AFD9F-8FC9-441E-8596-233A3A1A12B2@uclouvain.be> <0dffa8eb83420ae18d7f2e2e504bf8a0.squirrel@mmp.sipr-dc.ucl.ac.be> <4E21D4F6.6020008@raszuk.net> <6E900D06-62DE-4934-862D-C473C04ED90C@uclouvain.be> <4E23EAFB.3080604@raszuk.net> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 08:13:54 -0000 > And I am not saying LISP will or will not be able to handle it. I am > just asking how it will handle it ;) Maybe the answer is to in the > moment of exceeding capacity threshold of any xTR push some of the > traffic to few bigger proxies ... just a thought. Our LISP-MN implementation right now stores a single map-cache entry to a re-encapsulating LISP router. So just like you have a default route in a home router, you can have a default map-cache entry. And the data plane stretch can be the same if the re-encapsulating router is in the PE router provisioned with a product that has larger FIB capacity. And if that PE router is a PITR connected to the ALT, it knows right away if the destination is a LISP site or a non-LISP site. When the destination is a non-LISP site, it forwards packet in hardware because it has a FIB route (via BGP), and when the destination is a LISP site, it can send a Map-Request and build the map-cache. So the DOS attack on non-LISP sites is mitigated because BGP is in use and is no worse than today. A DOS attack on LISP sites can be bounded by the size of each EID-prefix. Not perfect, but that is what we have so far. Dino From luigi@net.t-labs.tu-berlin.de Tue Jul 19 01:16:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F86E21F87D9 for ; Tue, 19 Jul 2011 01:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.142 X-Spam-Level: X-Spam-Status: No, score=-4.142 tagged_above=-999 required=5 tests=[AWL=2.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsMRKf5awJBe for ; Tue, 19 Jul 2011 01:16:51 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80721F8541 for ; Tue, 19 Jul 2011 01:16:51 -0700 (PDT) Received: from dyn114.net.t-labs.tu-berlin.de (dyn114.net.t-labs.tu-berlin.de [130.149.220.114]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 145B970B5AE8; Tue, 19 Jul 2011 10:16:20 +0200 (CEST) From: Luigi Iannone Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--103785530 Date: Tue, 19 Jul 2011 10:16:19 +0200 In-Reply-To: To: Jeff Wheeler , lisp@ietf.org References: <20110718192145.2E8B818C1A3@mercury.lcs.mit.edu> Message-Id: <55EC36E5-281E-4925-B6A6-6A2796CEBD60@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.1084) Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 08:16:55 -0000 --Apple-Mail-8--103785530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 18, 2011, at 23:13 , Jeff Wheeler wrote: [snip] >=20 > It might not be unsolvable. I think the efforts of LISP developers > should be focused on this issue, as it is really the only huge, > show-stopping issue I see that makes it impractical for Internet-scale > use. If this problem can be overcome, LISP has a great potential. I > like the concept of LISP more than is apparent from my postings Happy to hear that you changed your mind from=20 "I personally believe LISP is a horrible idea that will have trouble = scaling up,..." in http://mailman.nanog.org/pipermail/nanog/2011-April/035131.html Luigi > -- but > I also live in the practical world where I see > 10Mpps DoS attacks > every day. --Apple-Mail-8--103785530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

It might not be unsolvable.  I think = the efforts of LISP developers
should be focused on this issue, as it = is really the only huge,
show-stopping issue I see that makes it = impractical for Internet-scale
use.  If this problem can be = overcome, LISP has a great potential.  I
like the concept of = LISP more than is apparent from my = postings

Happy to hear that you = changed your mind from 
"I personally = believe LISP is a horrible idea that will have trouble scaling up,..."

Luigi


-- but
I also live in the practical world where I = see > 10Mpps DoS attacks
every = day.

= --Apple-Mail-8--103785530-- From HeinerHummel@aol.com Tue Jul 19 04:30:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52B21F88DD for ; Tue, 19 Jul 2011 04:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS7hEUAnRyc0 for ; Tue, 19 Jul 2011 04:30:43 -0700 (PDT) Received: from imr-da02.mx.aol.com (imr-da02.mx.aol.com [205.188.105.144]) by ietfa.amsl.com (Postfix) with ESMTP id 933D621F88D9 for ; Tue, 19 Jul 2011 04:30:43 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da02.mx.aol.com (8.14.1/8.14.1) with ESMTP id p6JBUZCt030364; Tue, 19 Jul 2011 07:30:35 -0400 Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v42.9.) id l.f9d.121432f3 (44227); Tue, 19 Jul 2011 07:30:30 -0400 (EDT) Received: from smtprly-me01.mx.aol.com (smtprly-me01.mx.aol.com [64.12.95.102]) by cia-dd08.mx.aol.com (v129.10) with ESMTP id MAILCIADD085-b2b54e256ad43cd; Tue, 19 Jul 2011 07:30:30 -0400 Received: from webmail-m163 (webmail-m163.sim.aol.com [64.12.183.154]) by smtprly-me01.mx.aol.com (v129.10) with ESMTP id MAILSMTPRLYME017-b2b54e256ad43cd; Tue, 19 Jul 2011 07:30:28 -0400 References: <20110718192145.2E8B818C1A3@mercury.lcs.mit.edu> <55EC36E5-281E-4925-B6A6-6A2796CEBD60@net.t-labs.tu-berlin.de> To: luigi@net.t-labs.tu-berlin.de, jsw@inconcepts.biz, lisp@ietf.org Date: Tue, 19 Jul 2011 07:30:28 -0400 X-AOL-IP: 178.27.161.217 In-Reply-To: <55EC36E5-281E-4925-B6A6-6A2796CEBD60@net.t-labs.tu-berlin.de> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User Content-Type: multipart/alternative; boundary="--------MB_8CE141E65131061_16E0_4306E_webmail-m163.sysops.aol.com" X-Mailer: AOL Webmail 33972-STANDARD Received: from 178.27.161.217 by webmail-m163.sysops.aol.com (64.12.183.154) with HTTP (WebMailUI); Tue, 19 Jul 2011 07:30:28 -0400 Message-Id: <8CE141E650BEC3E-16E0-1F256@webmail-m163.sysops.aol.com> X-AOL-SENDER: HeinerHummel@aol.com Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 11:30:47 -0000 ----------MB_8CE141E65131061_16E0_4306E_webmail-m163.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" DoS attackers will discontinue doing DoS attacks, provided that a DoS att= ack fails to overload the attacked user. Cascade Tree Routing would limit the number of service requests to the pre= -assigned degree of cascading. Cascade Tree Routing would do so in case of multiple download requests wit= hin a particular time window, no matter whether these are honest or malici= ous and would BTW work like state-less Multicast. Heiner =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: Luigi Iannone An: Jeff Wheeler ; lisp@ietf.org Verschickt: Di., 19. Jul. 2011, 10:16 Betreff: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is= IPv6 broken?) On Jul 18, 2011, at 23:13 , Jeff Wheeler wrote: [snip] It might not be unsolvable. I think the efforts of LISP developers should be focused on this issue, as it is really the only huge, show-stopping issue I see that makes it impractical for Internet-scale use. If this problem can be overcome, LISP has a great potential. I like the concept of LISP more than is apparent from my postings Happy to hear that you changed your mind from=20 "I personally believe LISP is a horrible idea that will have trouble scali= ng up,..." in http://mailman.nanog.org/pipermail/nanog/2011-April/035131.html Luigi -- but I also live in the practical world where I see > 10Mpps DoS attacks every day. =3D =20 _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp =20 ----------MB_8CE141E65131061_16E0_4306E_webmail-m163.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" DoS attackers  will= discontinue doing DoS attacks, provided that a DoS attack fails to overlo= ad the attacked user.

Cascade Tree Routing would limit the number of service requests to th= e pre-assigned degree of cascading.

Cascade Tree Routing would do so in case of multiple download request= s within a particular time window, no matter whether these are honest or= malicious and would BTW work like state-less Multicast.

Heiner
 



----= -Urspr=C3=BCngliche Mitteilung-----
Von: Luigi Iannone <luigi@net.t-labs.tu-berlin.de>
An: Jeff Wheeler <jsw@inconcepts.biz>; lisp@ietf.org
Verschickt: Di., 19. Jul. 2011, 10:16
Betreff: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is= IPv6 broken?)


On Jul 18, 2011, at 23:13 , Jeff Wheeler wrote:

[snip]

It might not be unsolvable.  I think the efforts of LISP devel= opers
should be focused on this issue, as it is really the only huge,
show-stopping issue I see that makes it impractical for Internet-scale
use.  If this problem can be overcome, LISP has a great potential. &n= bsp;I
like the concept of LISP more than is apparent from my postings

Happy to hear that you changed your mind from 
"I personally believe LISP is a horrible idea that will= have trouble scaling up,..."

Luigi


-- but
I also live in the practical world where I see > 10Mpps DoS attacks
every day.

=3D 
_______________________________________=
________
lisp mailing list
lisp@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/lisp
=3D ----------MB_8CE141E65131061_16E0_4306E_webmail-m163.sysops.aol.com-- From jsw@inconcepts.biz Tue Jul 19 11:22:45 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5671021F8634 for ; Tue, 19 Jul 2011 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUUjjv9TzHsU for ; Tue, 19 Jul 2011 11:22:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62F9221F862F for ; Tue, 19 Jul 2011 11:22:44 -0700 (PDT) Received: by vxi40 with SMTP id 40so4197517vxi.31 for ; Tue, 19 Jul 2011 11:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.163 with SMTP id m3mr7673500vdv.244.1311099763417; Tue, 19 Jul 2011 11:22:43 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Tue, 19 Jul 2011 11:22:43 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Date: Tue, 19 Jul 2011 14:22:43 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=bcaec5016183a9e22e04a8703313 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:22:45 -0000 --bcaec5016183a9e22e04a8703313 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 19, 2011 at 3:21 AM, Patrick Frejborg wrote: > The reflective attack at an ITR can be prevented by a rate limiter (as > Noel pointed out), by identifying the botnet client by the source > address. But what if the botnet client changes randomly source address > within the subnet for each request?? Noel's suggestion is not to rate-limit based on Internet source addresses, or any layer-3 addresses in fact; but based on the layer-2 adjacency from which packets requiring a punt and MS resolve arrive at the ITR. So if you had a network like (please excuse my use of gmail Rich Text): Internet | ITR | switch / \ / \ host1 host2 Packets may arrive at the ITR from host1 at a huge rate and cause cache churn (DoS) but the ITR may have two policers, one for punts from host1 (based on L2 address) and one for punts from host2. The excessive punts from host1 may be marked-down to a lower priority so, when the limit of the punts the ITR can process is reached, host2 will still be able to establish communication to new clients, while host1 would be affected by the DoS directed against it. I have had a bit more time to think about this idea, and cache eviction is also a problem here. The traffic from host1 could still cause enough churn in the ITR that all mappings might be evicted from the FIB, which would then cause all hosts to appear to be churning even though they are sending only routine traffic. One might say, don't evict a "busy" cache entry to install a mapping for only one packet if the cache is currently full; but it is not safe to assume that an attack would not simply send several packets (in fact, TCP stack on host1 would do this normally, in the case of a reflection attack where it is sending SYN|ACK several times.) So even if punts are policed per L2ADJ, cache eviction is very much non-trivial in this situation. Would you decide to limit the amount of mappings that should be installed as a result of traffic from a single L2ADJ also? Refuse to evict entries on behalf of the L2ADJ that is hitting its punt policer during that time? In this case, a somewhat slower attack that does not reach that high water mark might still effectively DoS the ITR. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --bcaec5016183a9e22e04a8703313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2011 at 3:21 AM, Patrick Frejborg <pfrejborg@gmail.com> wrote:
> The reflective= attack at an ITR can be prevented by a rate limiter (as
> Noel point= ed out), by identifying the botnet client by the source
> address. But what if the botnet client changes randomly source address=
> within the subnet for each request??

Noel's suggestion = is not to rate-limit based on Internet source addresses, or any layer-3 add= resses in fact; but based on the layer-2 adjacency from which packets requi= ring a punt and MS resolve arrive at the ITR. =A0So if you had a network li= ke (please excuse my use of gmail Rich Text):

=A0 =A0 =A0 =A0Internet
=A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0ITR
=A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 = =A0 switch
= =A0 =A0 =A0 =A0 / =A0 =A0\
=A0 =A0 =A0 =A0/ =A0 =A0 =A0\
=A0 =A0 host1 =A0 =A0host2

Packets may arrive at the ITR from host1 at a huge rate= and cause cache churn (DoS) but the ITR may have two policers, one for pun= ts from host1 (based on L2 address) and one for punts from host2. =A0The ex= cessive punts from host1 may be marked-down to a lower priority so, when th= e limit of the punts the ITR can process is reached, host2 will still be ab= le to establish communication to new clients, while host1 would be affected= by the DoS directed against it.

I have had a bit more time to think about this idea, an= d cache eviction is also a problem here. =A0The traffic from host1 could st= ill cause enough churn in the ITR that all mappings might be evicted from t= he FIB, which would then cause all hosts to appear to be churning even thou= gh they are sending only routine traffic. =A0One might say, don't evict= a "busy" cache entry to install a mapping for only one packet if= the cache is currently full; but it is not safe to assume that an attack w= ould not simply send several packets (in fact, TCP stack on host1 would do = this normally, in the case of a reflection attack where it is sending SYN|A= CK several times.)

So even if punts are policed per L2ADJ, cache eviction = is very much non-trivial in this situation. =A0Would you decide to limit th= e amount of mappings that should be installed as a result of traffic from a= single L2ADJ also? =A0Refuse to evict entries on behalf of the L2ADJ that = is hitting its punt policer during that time? =A0In this case, a somewhat s= lower attack that does not reach that high water mark might still effective= ly DoS the ITR.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator=A0 /=A0 Innovati= ve Network Concepts

--bcaec5016183a9e22e04a8703313-- From jnc@mercury.lcs.mit.edu Tue Jul 19 13:25:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2A121F8B17 for ; Tue, 19 Jul 2011 13:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtrkhGHyvVRx for ; Tue, 19 Jul 2011 13:25:26 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2F39F21F8B13 for ; Tue, 19 Jul 2011 13:25:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 04B0818C1A8; Tue, 19 Jul 2011 16:25:25 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> Date: Tue, 19 Jul 2011 16:25:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:25:26 -0000 > From: Jeff Wheeler > cache eviction is also a problem here. The traffic from host1 could still > cause enough churn in the ITR that all mappings might be evicted from the > FIB, which would then cause all hosts to appear to be churning even > though they are sending only routine traffic. Hence my suggestion for partitioning the cache, to limit the part being thrashed. The thing is that partitioning the cache to prevent the entire cache being thrashed is a general strategy, which can be applied in all sorts of ways (see below). Note that 'partitioning the cache' is not the same as 'having separate caches' for each . The contents of the entire cache is still availble for all users, so that if client machine A causes the mapping for large content provider P to be cached, clients machines B, C, etc can all use that mapping. It's only partitioned so that attempts to thrash it only thrash a section of it, causing only some degradation of service, not denial. > One might say, don't evict a "busy" cache entry to install a mapping for > only one packet if the cache is currently full, but it is not safe to > assume that an attack would not simply send several packets One can easily imagine all sorts of ways to partition the cache, other than the one I suggested (which was to separate out highly-used mappings from new ones), if that proves to be not good enough. E.g. one could _also_ have code so that no individual client machine (i.e. source) can be the source of more than N% of the mappings, so that when a 'request' for the N+1th mapping arrives from that source, one of its oldest/least-used mappings gets evicted. Etc, etc, etc. It has been suggested that this might be a value-added differentiator for vendors, in fact - whose cache is most resistant to DoS? > (in fact, TCP stack on host1 would do this normally, in the case of a > reflection attack where it is sending SYN|ACK several times.) If that machine is a server, it probably out to be tweaked to not retransmit SYN-ACKs - if it's a legit connection, let the other end retransmit. Noel From pfrejborg@gmail.com Tue Jul 19 23:59:44 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642C821F874A for ; Tue, 19 Jul 2011 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnK0ooFs6hDl for ; Tue, 19 Jul 2011 23:59:41 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8123921F84F7 for ; Tue, 19 Jul 2011 23:59:38 -0700 (PDT) Received: by eya28 with SMTP id 28so666751eya.21 for ; Tue, 19 Jul 2011 23:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MWcwvKSFht35aIjvh2cbqzRaese+N5kIZWcV7TByBXs=; b=QBolgshvm84lMtbSdAiFh/mFIshCx9BhA2UGdbZN22ZQlJkzH07CUwp3VngJW2A4T1 jLlQXL+L1oHSUzbhHiGZNVYB4vCZp9to+zC+QqwPmjfpimzG+D9HDY+7WyAl6sfORZiv 0ZgsEZib4h5mKAzxsW31hgs6Hw9kSGfmFBOfU= MIME-Version: 1.0 Received: by 10.213.27.198 with SMTP id j6mr3017542ebc.88.1311145177269; Tue, 19 Jul 2011 23:59:37 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Tue, 19 Jul 2011 23:59:37 -0700 (PDT) In-Reply-To: References: <20110719004752.150C818C1A8@mercury.lcs.mit.edu> Date: Wed, 20 Jul 2011 09:59:37 +0300 Message-ID: From: Patrick Frejborg To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 06:59:44 -0000 On Tue, Jul 19, 2011 at 10:21 AM, Patrick Frejborg wr= ote: > On Tue, Jul 19, 2011 at 4:36 AM, Jeff Wheeler wrote: >> Perhaps I am confused about this, but my understanding is that the >> LISP community is quite interested in the ability to prevent source >> address spoofing and does want the ETR to somehow have this >> capability. =A0It has been suggested, in the past few days in fact, that >> it would be a tool for preventing the reflection-based ITR DoS I have >> supposed. =A0However, that is not possible if ETRs aren't able to do >> this. >> > > I believe this scenario is a real threat for cache churn, i.e. if the > ETR is going to prevent source address spoofing. The hacking culture > has recently moved into a new era, see > http://www.time.com/time/business/article/0,8599,2079423,00.html > > The communities do have really large botnets, with millions of > "clients". Depending on how the clients are located - worst case is > that each client is located at a specific DFZ prefix (which is not > likely) - a botnet might perhaps create a cache churn and there is no > way the ETR can separate fake traffic from real traffic. > I had some more thoughts about the ETR scenario... If there is an ETR then there is also an EID at the site, thus there is somewhere most likely an ITR related to that EID, right? So when the botnet clients are sending their SYN traffic through the ETR, the server replies with an ACK and then the ACK will hit the ITR. If the botnet clients are located in the EID name space the ITR will create needed cache entries - today this is not an issue because the testbed is quite small (compared to Internet), but if LISP deployment is successful the probability that botnet clients resides at prefix dispersed EIDs increases. And the more prefix dispersed botnet the community owns the more cache entries it can create at a selected ITR. I'm not an expert in LISP, thus do I miss something here? Patrick From jnc@mercury.lcs.mit.edu Wed Jul 20 07:14:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B920E21F86A2 for ; Wed, 20 Jul 2011 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+pjT5fbgozo for ; Wed, 20 Jul 2011 07:14:42 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4954D21F8658 for ; Wed, 20 Jul 2011 07:14:42 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 077BE18C1BA; Wed, 20 Jul 2011 10:14:41 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110720141441.077BE18C1BA@mercury.lcs.mit.edu> Date: Wed, 20 Jul 2011 10:14:41 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:14:42 -0000 > From: Patrick Frejborg > So when the botnet clients are sending their SYN traffic through the ETR, > the server replies with an ACK and then the ACK will hit the ITR. > ... > I'm not an expert in LISP, thus do I miss something here? Err, I think this is the same 'thrash ITRs with reflected traffic' problem we've been discussing for a while now? (And that is a real issue - I've gotten several private email messages of the form 'yeah, that's a real issue - we're glad someone brought it up so we can think about it'.) > if LISP deployment is successful the probability that botnet clients > resides at prefix dispersed EIDs increases. Actually, I don't think it matters whether the source address is an EID or a 'legacy' address - the ITR will still always have to talk to the MR to see if it's an EID. (The ITR can't rely on simply finding the destination in its local routing table, and assuming that means it's not an EID, since PITRs will be injecting routes to EIDs to make LISPed nodes accessible to legacy nodes.) Noel From rbonica@juniper.net Wed Jul 20 09:11:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1521F84DF for ; Wed, 20 Jul 2011 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhfc4Nn-qcg5 for ; Wed, 20 Jul 2011 09:11:24 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E921F84E8 for ; Wed, 20 Jul 2011 09:11:21 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTib+KTMiqcKnRcrtbVDuXQV0Ujl2njDH@postini.com; Wed, 20 Jul 2011 09:11:24 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Jul 2011 09:07:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 20 Jul 2011 12:07:55 -0400 From: Ronald Bonica To: Noel Chiappa , "jsw@inconcepts.biz" , "lisp@ietf.org" Date: Wed, 20 Jul 2011 12:07:53 -0400 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxGUgEk3NacNkArTS2kIP1eOQ6NYwAozhhg Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> In-Reply-To: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:11:25 -0000 > One can easily imagine all sorts of ways to partition the cache, other > than the > one I suggested (which was to separate out highly-used mappings from > new ones), > if that proves to be not good enough. E.g. one could _also_ have code > so that > no individual client machine (i.e. source) can be the source of more > than N% of > the mappings, so that when a 'request' for the N+1th mapping arrives > from that > source, one of its oldest/least-used mappings gets evicted. Etc, etc, > etc. >=20 > It has been suggested that this might be a value-added differentiator > for > vendors, in fact - whose cache is most resistant to DoS? >=20 Noel, At the risk of repeating myself, I think that the cache partitioning strate= gy should be spelled out in the specification. If we specify it, the strate= gy will benefit from wide review. If we don't specify a strategy, the specification should at least point out= that there is a sharp edge here, and that no strategy has been demonstrate= d to address all corner cases. Ron From jsw@inconcepts.biz Wed Jul 20 09:52:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C89F21F86A2 for ; Wed, 20 Jul 2011 09:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNXWWD9oZ0-l for ; Wed, 20 Jul 2011 09:52:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99AA921F8698 for ; Wed, 20 Jul 2011 09:52:29 -0700 (PDT) Received: by vws12 with SMTP id 12so381492vws.31 for ; Wed, 20 Jul 2011 09:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.163 with SMTP id m3mr8811550vdv.244.1311180749113; Wed, 20 Jul 2011 09:52:29 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Wed, 20 Jul 2011 09:52:28 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> Date: Wed, 20 Jul 2011 12:52:28 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:52:30 -0000 On Wed, Jul 20, 2011 at 12:07 PM, Ronald Bonica wrote= : > At the risk of repeating myself, I think that the cache partitioning stra= tegy should be spelled out in the specification. If we specify it, the stra= tegy will benefit from wide review. > > If we don't specify a strategy, the specification should at least point o= ut that there is a sharp edge here, and that no strategy has been demonstra= ted to address all corner cases. I favor your second suggestion. I do not think the specification should dictate how the cache is managed. Vendors should feel free to innovate in this area. I agree with Noel that some vendors will do a better job than others, and may even present the operator with configurable choices. Cisco is doing this in the area of ND Cache, which is a remarkably similar problem. The change I think is necessary is to make the MS protocol more flexible. The negative response problem I pointed out to start this discussion can be substantially improved by vendor implementations if the MS is able to reply with an aggregate negative mapping as well as one or more positive mappings (more-specifics.) I also still believe that operators may demand xTRs be able to carry all mappings in some situations, and the MS protocol should be capable of supplying that data. This permits vendors to build boxes with that feature, and large enough FIB, if they believe customers will buy them. -- Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jmh@joelhalpern.com Wed Jul 20 10:56:40 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7A21F8A97 for ; Wed, 20 Jul 2011 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L8K+zBrOmA6 for ; Wed, 20 Jul 2011 10:56:40 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id E35A221F89C1 for ; Wed, 20 Jul 2011 10:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2958932466F0; Wed, 20 Jul 2011 10:56:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-210.clppva.btas.verizon.net [71.161.50.210]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5303D3228BD8; Wed, 20 Jul 2011 10:56:38 -0700 (PDT) Message-ID: <4E2716CD.2030101@joelhalpern.com> Date: Wed, 20 Jul 2011 13:56:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:56:40 -0000 Let me suggest a different phrasing Ron... It would seem reasonable to include discussion of this issue in a document. However, I do not see that it needs to be in the base specs at this stage of the game. A separate additional work item, if we have folks willing and interested in doing so, seems sensible. Yours, Joel On 7/20/2011 12:07 PM, Ronald Bonica wrote: >> One can easily imagine all sorts of ways to partition the cache, other >> than the >> one I suggested (which was to separate out highly-used mappings from >> new ones), >> if that proves to be not good enough. E.g. one could _also_ have code >> so that >> no individual client machine (i.e. source) can be the source of more >> than N% of >> the mappings, so that when a 'request' for the N+1th mapping arrives >> from that >> source, one of its oldest/least-used mappings gets evicted. Etc, etc, >> etc. >> >> It has been suggested that this might be a value-added differentiator >> for >> vendors, in fact - whose cache is most resistant to DoS? >> > > > Noel, > > At the risk of repeating myself, I think that the cache partitioning strategy should be spelled out in the specification. If we specify it, the strategy will benefit from wide review. > > If we don't specify a strategy, the specification should at least point out that there is a sharp edge here, and that no strategy has been demonstrated to address all corner cases. > > Ron > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From rbonica@juniper.net Wed Jul 20 11:48:34 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4E21F8B1A for ; Wed, 20 Jul 2011 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sr0I1g0lPUC for ; Wed, 20 Jul 2011 11:48:33 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 54F6921F8AD8 for ; Wed, 20 Jul 2011 11:48:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTici+pOUJZNHrOmz3n9rCGWSqEYj2GBv@postini.com; Wed, 20 Jul 2011 11:48:33 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Jul 2011 11:45:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 20 Jul 2011 14:45:55 -0400 From: Ronald Bonica To: "Joel M. Halpern" Date: Wed, 20 Jul 2011 14:45:53 -0400 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxHBmLSKxijiiZNQE+2mEbb8BFoawABpJww Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F40F2AB4@EMBX01-WF.jnpr.net> References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> <4E2716CD.2030101@joelhalpern.com> In-Reply-To: <4E2716CD.2030101@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:48:34 -0000 Joel, I am fine with Jeff's proposal. We can simply note that "there is a sharp e= dge here, and that no strategy has been demonstrated to address all corner cases." When the issue has been ade= quately addressed, we can issue a bis document that does not include the ca= veat. Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, July 20, 2011 1:56 PM > To: Ronald Bonica > Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why > is IPv6 broken?) >=20 > Let me suggest a different phrasing Ron... > It would seem reasonable to include discussion of this issue in a > document. However, I do not see that it needs to be in the base specs > at this stage of the game. A separate additional work item, if we have > folks willing and interested in doing so, seems sensible. >=20 > Yours, > Joel >=20 > On 7/20/2011 12:07 PM, Ronald Bonica wrote: > >> One can easily imagine all sorts of ways to partition the cache, > other > >> than the > >> one I suggested (which was to separate out highly-used mappings from > >> new ones), > >> if that proves to be not good enough. E.g. one could _also_ have > code > >> so that > >> no individual client machine (i.e. source) can be the source of more > >> than N% of > >> the mappings, so that when a 'request' for the N+1th mapping arrives > >> from that > >> source, one of its oldest/least-used mappings gets evicted. Etc, > etc, > >> etc. > >> > >> It has been suggested that this might be a value-added > differentiator > >> for > >> vendors, in fact - whose cache is most resistant to DoS? > >> > > > > > > Noel, > > > > At the risk of repeating myself, I think that the cache partitioning > strategy should be spelled out in the specification. If we specify it, > the strategy will benefit from wide review. > > > > If we don't specify a strategy, the specification should at least > point out that there is a sharp edge here, and that no strategy has > been demonstrated to address all corner cases. > > > > Ron > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp > > From jmh@joelhalpern.com Wed Jul 20 12:02:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BD21F8AA8 for ; Wed, 20 Jul 2011 12:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh7dguofwyYS for ; Wed, 20 Jul 2011 12:02:55 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id EC48F21F8A80 for ; Wed, 20 Jul 2011 12:01:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 40DDB3228BD7; Wed, 20 Jul 2011 12:01:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-210.clppva.btas.verizon.net [71.161.50.210]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 39C1D3245BAA; Wed, 20 Jul 2011 12:01:44 -0700 (PDT) Message-ID: <4E27260F.5040401@joelhalpern.com> Date: Wed, 20 Jul 2011 15:01:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> <4E2716CD.2030101@joelhalpern.com> <13205C286662DE4387D9AF3AC30EF456D3F40F2AB4@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F40F2AB4@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:02:55 -0000 There already is warning text on this in the document. If we are going to add yet more warning to the documents we are currently working on, I would want to see specific proposed text with a specific placement. Thank you, Joel On 7/20/2011 2:45 PM, Ronald Bonica wrote: > Joel, > > I am fine with Jeff's proposal. We can simply note that "there is a sharp edge here, and that no strategy has > been demonstrated to address all corner cases." When the issue has been adequately addressed, we can issue a bis document that does not include the caveat. > > Ron > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, July 20, 2011 1:56 PM >> To: Ronald Bonica >> Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org >> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why >> is IPv6 broken?) >> >> Let me suggest a different phrasing Ron... >> It would seem reasonable to include discussion of this issue in a >> document. However, I do not see that it needs to be in the base specs >> at this stage of the game. A separate additional work item, if we have >> folks willing and interested in doing so, seems sensible. >> >> Yours, >> Joel >> >> On 7/20/2011 12:07 PM, Ronald Bonica wrote: >>>> One can easily imagine all sorts of ways to partition the cache, >> other >>>> than the >>>> one I suggested (which was to separate out highly-used mappings from >>>> new ones), >>>> if that proves to be not good enough. E.g. one could _also_ have >> code >>>> so that >>>> no individual client machine (i.e. source) can be the source of more >>>> than N% of >>>> the mappings, so that when a 'request' for the N+1th mapping arrives >>>> from that >>>> source, one of its oldest/least-used mappings gets evicted. Etc, >> etc, >>>> etc. >>>> >>>> It has been suggested that this might be a value-added >> differentiator >>>> for >>>> vendors, in fact - whose cache is most resistant to DoS? >>>> >>> >>> >>> Noel, >>> >>> At the risk of repeating myself, I think that the cache partitioning >> strategy should be spelled out in the specification. If we specify it, >> the strategy will benefit from wide review. >>> >>> If we don't specify a strategy, the specification should at least >> point out that there is a sharp edge here, and that no strategy has >> been demonstrated to address all corner cases. >>> >>> Ron >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>> > From rbonica@juniper.net Wed Jul 20 13:01:40 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169C21F84FC for ; Wed, 20 Jul 2011 13:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNue7rauAwYc for ; Wed, 20 Jul 2011 13:01:39 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8021F86D1 for ; Wed, 20 Jul 2011 13:01:34 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTic0HEtEKGvQr1xBW0to9ZpPb0IZeF4q@postini.com; Wed, 20 Jul 2011 13:01:38 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 20 Jul 2011 13:00:28 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 20 Jul 2011 16:00:28 -0400 From: Ronald Bonica To: "Joel M. Halpern" Date: Wed, 20 Jul 2011 16:00:26 -0400 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxHD3oLPMYhdeCmRP+wOGt6KlOf+AACBz6A Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F40F2CB2@EMBX01-WF.jnpr.net> References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> <4E2716CD.2030101@joelhalpern.com> <13205C286662DE4387D9AF3AC30EF456D3F40F2AB4@EMBX01-WF.jnpr.net> <4E27260F.5040401@joelhalpern.com> In-Reply-To: <4E27260F.5040401@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:01:40 -0000 I will generate some text late this week. Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, July 20, 2011 3:02 PM > To: Ronald Bonica > Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why > is IPv6 broken?) >=20 > There already is warning text on this in the document. > If we are going to add yet more warning to the documents we are > currently working on, I would want to see specific proposed text with a > specific placement. >=20 > Thank you, > Joel >=20 > On 7/20/2011 2:45 PM, Ronald Bonica wrote: > > Joel, > > > > I am fine with Jeff's proposal. We can simply note that "there is a > sharp edge here, and that no strategy has > > been demonstrated to address all corner cases." When the issue has > been adequately addressed, we can issue a bis document that does not > include the caveat. > > > > Ron > > > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, July 20, 2011 1:56 PM > >> To: Ronald Bonica > >> Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > >> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: > Why > >> is IPv6 broken?) > >> > >> Let me suggest a different phrasing Ron... > >> It would seem reasonable to include discussion of this issue in a > >> document. However, I do not see that it needs to be in the base > specs > >> at this stage of the game. A separate additional work item, if we > have > >> folks willing and interested in doing so, seems sensible. > >> > >> Yours, > >> Joel > >> > >> On 7/20/2011 12:07 PM, Ronald Bonica wrote: > >>>> One can easily imagine all sorts of ways to partition the cache, > >> other > >>>> than the > >>>> one I suggested (which was to separate out highly-used mappings > from > >>>> new ones), > >>>> if that proves to be not good enough. E.g. one could _also_ have > >> code > >>>> so that > >>>> no individual client machine (i.e. source) can be the source of > more > >>>> than N% of > >>>> the mappings, so that when a 'request' for the N+1th mapping > arrives > >>>> from that > >>>> source, one of its oldest/least-used mappings gets evicted. Etc, > >> etc, > >>>> etc. > >>>> > >>>> It has been suggested that this might be a value-added > >> differentiator > >>>> for > >>>> vendors, in fact - whose cache is most resistant to DoS? > >>>> > >>> > >>> > >>> Noel, > >>> > >>> At the risk of repeating myself, I think that the cache > partitioning > >> strategy should be spelled out in the specification. If we specify > it, > >> the strategy will benefit from wide review. > >>> > >>> If we don't specify a strategy, the specification should at least > >> point out that there is a sharp edge here, and that no strategy has > >> been demonstrated to address all corner cases. > >>> > >>> Ron > >>> > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >>> > > From Fred.L.Templin@boeing.com Wed Jul 20 14:51:23 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5641921F8546 for ; Wed, 20 Jul 2011 14:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9pPkovH-8Gk for ; Wed, 20 Jul 2011 14:51:23 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id F04C121F8541 for ; Wed, 20 Jul 2011 14:51:22 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6KLpHnF010895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2011 14:51:20 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6KLpHIJ011651; Wed, 20 Jul 2011 14:51:17 -0700 (PDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6KLpHKv011647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 20 Jul 2011 14:51:17 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 20 Jul 2011 14:51:17 -0700 From: "Templin, Fred L" To: Jeff Wheeler , "lisp@ietf.org" Date: Wed, 20 Jul 2011 14:51:16 -0700 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxG/WxIUhOeFcz6ThC8gEBWderHlgAKT8qA Message-ID: References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:51:23 -0000 Jeff, I would be interested in your assessment of whether this caching issue applies also to IRON [RFC6179]. I think it probably doesn't, because the IRON tunnel endpoints are not trying to hold all recently heard from correspondents in their cache, but I would be interested to hear what you think. Thanks - Fred= From jsw@inconcepts.biz Wed Jul 20 16:26:39 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9921F867F for ; Wed, 20 Jul 2011 16:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-7oB0kXEDzt for ; Wed, 20 Jul 2011 16:26:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8280C21F8509 for ; Wed, 20 Jul 2011 16:26:34 -0700 (PDT) Received: by vws12 with SMTP id 12so653291vws.31 for ; Wed, 20 Jul 2011 16:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.38.130 with SMTP id b2mr2387133vce.184.1311204393881; Wed, 20 Jul 2011 16:26:33 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Wed, 20 Jul 2011 16:26:33 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> Date: Wed, 20 Jul 2011 19:26:33 -0400 Message-ID: From: Jeff Wheeler To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:26:39 -0000 On Wed, Jul 20, 2011 at 5:51 PM, Templin, Fred L wrote: > I would be interested in your assessment of whether > this caching issue applies also to IRON [RFC6179]. I am not familiar with this work, and have only had a chance to skim RFC6179. However, it appears to me that IRON does not direct the IRON routers specifically to employ a cache, and indeed within each VPC, the routing protocol used to manage the VP may be different from others. So unlike LISP, which essentially requires the use of cache-based FIB and the LISP MS protocol for routing state, a VPC could choose to implement whatever they decide is smart for their own application, or purchase equipment from a vendor who has implemented what they feel is adequate. > I think it probably doesn't, because the IRON tunnel > endpoints are not trying to hold all recently heard > from correspondents in their cache, but I would be > interested to hear what you think. The problems I have been discussing with LISP are not related to payload buffering, but to routing state. One thing that jumps out at me about IRON, and keep in mind I have only skimmed the RFC and I may be incorrect, but I believe that, within a given VPC, malicious host H might send encapsulated packets to server A, when in fact server C is responsible for routing for those packets' destination EP. I believe IRON specifies that server A would do two things in this scenario; 1) forward the packet to server C, and 2) send a redirect back to the Locator address in the outer-header (probably not host H's address, but a forged/spoofed address.) This would allow the use of server A for reflecting an attack against server C, and also, some other Locator would receive redirect messages at whatever rate they are generated. This seems less than ideal. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From pfrejborg@gmail.com Thu Jul 21 00:03:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B421F8A97 for ; Thu, 21 Jul 2011 00:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN77-gk78k03 for ; Thu, 21 Jul 2011 00:03:15 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7BA21F8877 for ; Thu, 21 Jul 2011 00:03:15 -0700 (PDT) Received: by eya28 with SMTP id 28so1493201eya.21 for ; Thu, 21 Jul 2011 00:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZOkxyN2Rq4XMBn9tRPOd9rzguYG7ZvRWbrZKy/6onRc=; b=NhPlSbqwGIW+SsARlBbw1fxPeTyWQTZj1SSYRjGKNCW3iuiYWAcuttTd1thNkz7RZg HyjzDINmirjHzbLzCW8iqinVbV83OiORF5YhxepZ5hdwVNXBipcCKGjp7HUTS03klMWK uQpfjuLxvfFtCDANi1ThaLqN0g/3iw2kVSftg= MIME-Version: 1.0 Received: by 10.213.105.76 with SMTP id s12mr71723ebo.126.1311231794312; Thu, 21 Jul 2011 00:03:14 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Thu, 21 Jul 2011 00:03:13 -0700 (PDT) In-Reply-To: <20110720141441.077BE18C1BA@mercury.lcs.mit.edu> References: <20110720141441.077BE18C1BA@mercury.lcs.mit.edu> Date: Thu, 21 Jul 2011 10:03:13 +0300 Message-ID: From: Patrick Frejborg To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:03:16 -0000 On Wed, Jul 20, 2011 at 5:14 PM, Noel Chiappa wro= te: > =A0 =A0> From: Patrick Frejborg > > =A0 =A0> So when the botnet clients are sending their SYN traffic through= the ETR, > =A0 =A0> the server replies with an ACK and then the ACK will hit the ITR= . > =A0 =A0> ... > =A0 =A0> I'm not an expert in LISP, thus do I miss something here? > > Err, I think this is the same 'thrash ITRs with reflected traffic' proble= m > we've been discussing for a while now? (And that is a real issue - I've g= otten > several private email messages of the form 'yeah, that's a real issue - w= e're > glad someone brought it up so we can think about it'.) Yes, right - but I think there are two use cases in our discussions; external attack and internal attack scenarios. In the external attack scenario the botnet clients ACKs might overwhelm the ITR and this one is hard to mitigate. The internal attack is coming from an infected endpoint inside the EID space, it might use different source addresses to avoid a rate limiter at the ITR. Jeff suggested a L2 adjacency mechanism but I feel that approach is not suitable for most of the enterprises. These usually have a security architecture with several security zones and with a "defense in depth" principle in place, thus there will a bunch of security nodes/middleboxes between the ITR and endpoints. To mitigate this risk, the enterprise should install IDS/IDP devices at the L2 segments where there is a risk for infected endpoints. > > =A0 =A0> if LISP deployment is successful the probability that botnet cli= ents > =A0 =A0> resides at prefix dispersed EIDs increases. > > Actually, I don't think it matters whether the source address is an EID o= r a > 'legacy' address - the ITR will still always have to talk to the MR to se= e if > it's an EID. (The ITR can't rely on simply finding the destination in its= local > routing table, and assuming that means it's not an EID, since PITRs will = be > injecting routes to EIDs to make LISPed nodes accessible to legacy nodes.= ) > I believe your statement is correct for the punting issue - I didn't realize this situation until Jeff brought it up and you spelled out the details above. But for the cache trash issue you need to take into account how many botnet clients might be located at dispersed EID prefixes and how many entries (positive and negative) they create. An example, after five years from today, LISP has been deployed and there is a botnet with 2 million clients - 10% is located at dispersed EID prefixes and each client generates 1-10 entries in the mapping system. To sustain an attack the ITR should have a FIB of somewhere between 200k - 2 million entries. On the other hand, in the current system we have about 350 entries today - how many entries will there be in that system after 5 years... Thanks for the clarification and I hope I'm on the same page now Patrick From jsw@inconcepts.biz Thu Jul 21 00:52:09 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4321F8B4B for ; Thu, 21 Jul 2011 00:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsbOlNYGT-7J for ; Thu, 21 Jul 2011 00:52:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6916921F8B4A for ; Thu, 21 Jul 2011 00:52:08 -0700 (PDT) Received: by vxi40 with SMTP id 40so881607vxi.31 for ; Thu, 21 Jul 2011 00:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.161 with SMTP id dh1mr9949377vdc.177.1311234727675; Thu, 21 Jul 2011 00:52:07 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Thu, 21 Jul 2011 00:52:07 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: <20110720141441.077BE18C1BA@mercury.lcs.mit.edu> Date: Thu, 21 Jul 2011 03:52:07 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a8e562908a604a88fa0d9 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:52:09 -0000 --bcaec51a8e562908a604a88fa0d9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 21, 2011 at 3:03 AM, Patrick Frejborg wrote: > The internal attack is coming from an infected endpoint inside the EID > space, it might use different source addresses to avoid a rate limiter > at the ITR. Jeff suggested a L2 adjacency mechanism but I feel that > approach is not suitable for most of the enterprises. These usually > have a security architecture with several security zones and with a > "defense in depth" principle in place, thus there will a bunch of > security nodes/middleboxes between the ITR and endpoints. To mitigate > this risk, the enterprise should install IDS/IDP devices at the L2 > segments where there is a risk for infected endpoints. Also troubling is that IDS implies a whack-a-mole strategy which is not practical in a mixed-use data-center environment, where compromised machines are more common, IDS is not practical, and detection does not happen until there are actionable abuse reports or serious DoS originated by the machines. As you mention, the L2ADJ-based policer will not work for these networks if the ITR is a more centralized device with layer-3 devices between the ITR and untrustworthy downstream hosts. In most of my networks, we would not be able to push ITRs further toward the hosts. It is simply not cost-effective for us to have many boxes with large L3 FIB. Our typical L3 aggregation box is a Cisco 3750G or Juniper EX4200 -- these are 1RU switches with <= 16k IPv4 FIB and considerably smaller IPv6. These boxes can't be a good ITR for us because, especially after using a lot of FIB for customer routes, they would not even have enough FIB for a routine working set, let alone survive DoS churn. Our DFZ routers would work fine as an ITR in a "cache-less implementation" with today's Internet basically projected onto LISP, but with scaling up SOHO multi-homed networks that would not be true. Also, with expected IPv6 growth plus caching (and negative cache entry problem) even *without* scaling up SOHO multi-homing, they would not work as ITRs. And the L2ADJ-based punt/churn mitigation mechanism would not work for this design since the DFZ router is distant, by L3, from the untrustworthy downstream hosts. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --bcaec51a8e562908a604a88fa0d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2011 at 3:03 AM, Patrick Frejborg <pfrejborg@gmail.com> wrote:
> The internal a= ttack is coming from an infected endpoint inside the EID
> space, it = might use different source addresses to avoid a rate limiter
> at the ITR. Jeff suggested a L2 adjacency mechanism but I feel that> approach is not suitable for most of the enterprises. These usually> have a security architecture with several security zones and with a<= br> > "defense in depth" principle in place, thus there will a bun= ch of
> security nodes/middleboxes between the ITR and endpoints. To = mitigate
> this risk, the enterprise should install IDS/IDP devices a= t the L2
> segments where there is a risk for infected endpoints.

Also tro= ubling is that IDS implies a whack-a-mole strategy which is not practical i= n a mixed-use data-center environment, where compromised machines are more = common, IDS is not practical, and detection does not happen until there are= actionable abuse reports or serious DoS originated by the machines. =A0As = you mention, the L2ADJ-based policer will not work for these networks if th= e ITR is a more centralized device with layer-3 devices between the ITR and= untrustworthy downstream hosts.

In most of my networks, we would not be able to push IT= Rs further toward the hosts. =A0It is simply not cost-effective for us to h= ave many boxes with large L3 FIB. =A0Our typical L3 aggregation box is a Ci= sco 3750G or Juniper EX4200 -- these are 1RU switches with <=3D 16k IPv4= FIB and considerably smaller IPv6. =A0These boxes can't be a good ITR = for us because, especially after using a lot of FIB for customer routes, th= ey would not even have enough FIB for a routine working set, let alone surv= ive DoS churn.

Our DFZ routers would work fine as an ITR in a "ca= che-less implementation" with today's Internet basically projected= onto LISP, but with scaling up SOHO multi-homed networks that would not be= true. =A0Also, with expected IPv6 growth plus caching (and negative cache = entry problem) even *without* scaling up SOHO multi-homing, they would not = work as ITRs. =A0And the L2ADJ-based punt/churn mitigation mechanism would = not work for this design since the DFZ router is distant, by L3, from the u= ntrustworthy downstream hosts.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator=A0 /=A0 Innovati= ve Network Concepts

--bcaec51a8e562908a604a88fa0d9-- From dino@cisco.com Thu Jul 21 02:13:11 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E521F8B8D for ; Thu, 21 Jul 2011 02:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.991 X-Spam-Level: X-Spam-Status: No, score=-4.991 tagged_above=-999 required=5 tests=[AWL=-3.191, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFE4ynxldq3Q for ; Thu, 21 Jul 2011 02:13:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BE47721F8B7A for ; Thu, 21 Jul 2011 02:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2387; q=dns/txt; s=iport; t=1311239590; x=1312449190; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date; bh=8PqgbRe0fLGXKCjoyIq56suwIQeY/OcCNqB+fWEAnqo=; b=BIHhZoPRmRlhmfTD59WSOqCz8en6uT7VPqNI6OA4roMIzTkfxYi9DQC+ ZUXXgxsEFxmFSvgeOrCOQQcKYlgA3bHYAQtTO/HkvVnJxbfLDc8k/I0x1 /a+VUqTz/Jdt6YmIWJ3EWPJ2JyGO1X3aDUjEvSqcfMRBR/MNZLyma96a9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYGAJ3sJ06rRDoJ/2dsb2JhbABUmF6PCXelU4EjnhuFX18Eh1WLGYUHi3Y X-IronPort-AV: E=Sophos;i="4.67,240,1309737600"; d="scan'208";a="5033862" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2011 09:13:09 +0000 Received: from [192.168.1.6] ([10.21.70.209]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6L9D9sJ010166 for ; Thu, 21 Jul 2011 09:13:09 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jul 2011 02:13:09 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:13:11 -0000 Sorry for my silence but I have caught up on this really good thread. I think everyone is learning from each other as well as being challenged. This is goodness. To mitigate the DoS attack problem on filling up an ITR cache, uRPF can be done at these places in the network: (1) At the ITR (2) At the PE router connecting the site's ITR to the service provider PE (3) At the ETR (4) At a firewall router anywhere in the path. I believe (3) and (4) shared the same disadvantages. Many have mentioned doing it at the ETR. It can be done there but it requires more work and in my opinion it is done too late in the data path. Ditto for a firewall at the destination site. The best place is (1) and if you have a non-compromised ITR but compromised hosts, the ITR will drop packets that come from a spoofed EID. Today, if an ITR gets a packet from a source at the site where it does not match its EID-prefixes it will forward the packet natively because it thinks the packet is coming from an RLOC and going to either a non-LISP or LISP site (the destination doesn't matter for this discussion). We need to support this because a site might be partially converted to LISP so some hosts are assigned EIDs but others are not. When an ITR is configured with "LISP-based uRPF checking", and is a fully converted to a LISP site, it can drop packets before ever leaving the site. This way an EID-prefix associated with a locator-set is consistent for any packets leaving the site. And that mapping is the same mapping registered to the mapping database system. The destination sites will not have to participate in the solution and won't have to do mapping database lookups during decapsulation (and therefore don't have to fill their cache up for uRPF reasons). If we wanted cooperation from the service provider, the PE router could look deeper into the packet to verify the source EID in the packet is from a customer that owns it. This would require configuration of EID-prefixes (in ACLs perhaps) so it may be an OpEx burden. But having a PE router modified to look deeper into the packet is not much of a concern since the LISP encapsulation header is fixed length and the source EID can be found easily. This is one way to protect remote ITR caches from reflection attacks. Dino From dino@cisco.com Thu Jul 21 02:13:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5012821F8B95 for ; Thu, 21 Jul 2011 02:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.145 X-Spam-Level: X-Spam-Status: No, score=-5.145 tagged_above=-999 required=5 tests=[AWL=-2.546, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj-IrJ2JyY4R for ; Thu, 21 Jul 2011 02:13:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9581521F8B93 for ; Thu, 21 Jul 2011 02:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=3588; q=dns/txt; s=iport; t=1311239604; x=1312449204; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date; bh=hTwPTyuX//OBN8kc+1MmJppjVbBA5txFfAju0ogDBQc=; b=dZ/Jh/kVB8AB2EzBrnz/OVGzj6VQx9o7UKA6vxRlJAlLKqSSOvtsinEI 01tsyU49Taf+Sq6ugtC/SfqjQAMZrbeC1SBGztWfoo9fGl6n3yulaM1Mj TLQQUVxcCKTQ+3Se/b/hLi6jZ8Q2AiLToBZLt+MN+tWYb5zisfu1O2Uov o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIbtJ06rRDoJ/2dsb2JhbABUp2d3pU6BI54bhV9fBIdVixmFB4t2 X-IronPort-AV: E=Sophos;i="4.67,240,1309737600"; d="scan'208";a="5031449" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jul 2011 09:13:12 +0000 Received: from [192.168.1.6] ([10.21.70.209]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6L9D9sK010166 for ; Thu, 21 Jul 2011 09:13:11 GMT Message-Id: From: Dino Farinacci To: lisp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jul 2011 02:13:11 -0700 X-Mailer: Apple Mail (2.936) Subject: [lisp] FIB compression as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:13:25 -0000 It has been stated that if the granularity of prefixes in negative Map- Replies are too specific, we can fill up a cache. There are two ways to deal with this: (1) Use some form of aggregation or table compression. (2) Don't store negative prefixes. Jeff mentioned for (1) to have the mapping system return a coarse negative prefix with positive ones which punch holes in negative map- replies. This will be quite hard since the sender of the negative Map- Reply may not know all positive entries (since they are spread around and stored in other map-servers). But the map-server could infer based on looking at the ALT to find positive entries. So some research can be done on this idea to see if is tractable. Another way to tackle (1) is to have the ITR look at the more-specific negative prefixes to see if they can be combined into a fewer number of more coarse prefixes using localized prefix compression. If exact compression can be done, then do it (meaning their are no positive holes in the compressed aggregate). If there are holes created, they *could be mitigated* if you already have a positive cache entry stored because you previously have encapsulated to the site. But you can't always depend on this ordering to make it reliable. As for (2), we could say, we'll make a tradeoff by saving the cache at the expense of more load on the mapping system. Well the mapping system (like DNS) has to be provisioned and capacity planned to handle load for scaling reasons. So it should also be able to handle DoS load too. And if it can't, then the DoS load gets dropped (that is the good news). But with every DoS load that gets dropped there is good load that loses too. So take this with a grain of salt. But if the ITRs only stored positive cache entries, one might think we would not know when to forward natively to non-LISP sites. Well when an ITR gets a cache miss, it could send the packet natively as well as send a rate-limited Map-Request. We do implement very short-lived data- caches so we can do aggressive rate-limiting. If a Map-Reply is returned, you know the destination is a LISP site and you cache the positive entry. If nothing comes back, you continue to forward natively. As I said, this puts more Map-Request load on the mapping system. Or maybe a combination can be used. You store negative entries to a threshold and when you need to store a positive, it is the negative ones that are evicted first to make room for the positive ones. And which negative ones you choose to evict can the most specific prefixes because they represent a smaller set of destinations and the probability of sending a Map-Request for them to find out if they are LISP destinations or not is less likely then with larger blocks. Note, it is easier to compress negative map-cache entries since their locator-set is the same. That is it is empty with an action of "native- forward" where as for positive map-cache entries you cannot compress consecutive power-of-2 blocks if the locator-set is different (meaning the EID-prefixes belong to different sites). Now, there is always the option to take the compressed value and use a new locator, perhaps a re-encapsulating router in the core, that can hold more prefixes. This is related to my other email where a PETR can be used where it decapsulates from the ITR and re-encapsulates directly to the site. This will be at the expense of possible added data-plane stretch. Dino From jsw@inconcepts.biz Thu Jul 21 03:12:17 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4729A21F87BC for ; Thu, 21 Jul 2011 03:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBEeQx8ec3Tb for ; Thu, 21 Jul 2011 03:12:16 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7FE21F8591 for ; Thu, 21 Jul 2011 03:12:16 -0700 (PDT) Received: by vxi40 with SMTP id 40so965706vxi.31 for ; Thu, 21 Jul 2011 03:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.197 with SMTP id g5mr8415vcx.254.1311243135322; Thu, 21 Jul 2011 03:12:15 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Thu, 21 Jul 2011 03:12:15 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: Date: Thu, 21 Jul 2011 06:12:15 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=0016e64079284b89e204a891954f Subject: Re: [lisp] FIB compression as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 10:12:17 -0000 --0016e64079284b89e204a891954f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci wrote: > Jeff mentioned for (1) to have the mapping system return a coarse negative > prefix with positive ones which punch holes in negative map-replies. This > will be quite hard since the sender of the negative Map-Reply may not know > all positive entries (since they are spread around and stored in other > map-servers). But the map-server could infer based on looking at the ALT to > find positive entries. So some research can be done on this idea to see if > is tractable. > It would be possible to install shorter negative plus one or more longer positives that are not complete mappings, but "next-hop ms-resolve," which would discard packets to the shorter negative but still be able to punt and do MS query for the possibly-positive part of the address space. If I was the implementer, I would probably then keep count in my Trie to know when a particular branch of the address space cache contains mostly negative entries, which would indicate opportunities for on-demand "compression." Another way to tackle (1) is to have the ITR look at the more-specific > negative prefixes to see if they can be combined into a fewer number of more > coarse prefixes using localized prefix compression. If exact compression can > be done, then do it (meaning their are no positive holes in the compressed > aggregate). If there are holes created, they *could be mitigated* if you > already have a positive cache entry stored because you previously have > encapsulated to the site. But you can't always depend on this ordering to > make it reliable. > I do not understand how this can be beneficial if the MS currently sends negative replies that are the shortest possible prefixes which do not overlap any possible positive mapping. Keep in mind that my understanding of the control-plane remains limited, specifically I am not familiar with how much state is available from the local MS vs what must be retrieved from distant MS. I need to do some homework in this area. > As for (2), we could say, we'll make a tradeoff by saving the cache at the > expense of more load on the mapping system. Well the mapping system (like > DNS) has to be provisioned and capacity planned to handle load for scaling > reasons. So it should also be able to handle DoS load too. And if it can't, > then the DoS load gets dropped (that is the good news). But with every DoS > load that gets dropped there is good load that loses too. So take this with > a grain of salt. > > But if the ITRs only stored positive cache entries, one might think we > would not know when to forward natively to non-LISP sites. Well when an ITR > gets a cache miss, it could send the packet natively as well as send a > rate-limited Map-Request. We do implement very short-lived data-caches so we > can do aggressive rate-limiting. If a Map-Reply is returned, you know the > destination is a LISP site and you cache the positive entry. If nothing > comes back, you continue to forward natively. As I said, this puts more > Map-Request load on the mapping system. > I do not understand how this can be effective. If the ITR does not have a native Locator address for the payload address family, and the site is relying upon LISP, there won't be a way for packets to even reach the "native Internet" for some alternate forwarding to the destination. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --0016e64079284b89e204a891954f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci = <dino@cisco.com&= gt; wrote:
Jeff mentioned for (1) to have the mapping system return a coarse negative = prefix with positive ones which punch holes in negative map-replies. This w= ill be quite hard since the sender of the negative Map-Reply may not know a= ll positive entries (since they are spread around and stored in other map-s= ervers). But the map-server could infer based on looking at the ALT to find= positive entries. So some research can be done on this idea to see if is t= ractable.

It would be possible to install shorter ne= gative plus one or more longer positives that are not complete mappings, bu= t "next-hop ms-resolve," which would discard packets to the short= er negative but still be able to punt and do MS query for the possibly-posi= tive part of the address space.

If I was the=A0implementer, I would probably then keep = count in my Trie to know when a particular branch of the address space cach= e contains mostly negative entries, which would indicate opportunities for = on-demand "compression."

Another way to tackle (1) is to have the ITR look at the more-specific nega= tive prefixes to see if they can be combined into a fewer number of more co= arse prefixes using localized prefix compression. If exact compression can = be done, then do it (meaning their are no positive holes in the compressed = aggregate). If there are holes created, they *could be mitigated* if you al= ready have a positive cache entry stored because you previously have encaps= ulated to the site. But you can't always depend on this ordering to mak= e it reliable.

I do not understand how this can be benefi= cial if the MS currently sends negative replies that are the shortest possi= ble prefixes which do not overlap any possible positive mapping. =A0Keep in= mind that my understanding of the control-plane remains limited, specifica= lly I am not familiar with how much state is available from the local MS vs= what must be retrieved from distant MS. =A0I need to do some homework in t= his area.
=A0
As for (2), we could say, we'll make a tradeoff by saving the cache at = the expense of more load on the mapping system. Well the mapping system (li= ke DNS) has to be provisioned and capacity planned to handle load for scali= ng reasons. So it should also be able to handle DoS load too. And if it can= 't, then the DoS load gets dropped (that is the good news). But with ev= ery DoS load that gets dropped there is good load that loses too. So take t= his with a grain of salt.

But if the ITRs only stored positive cache entries, one might think we woul= d not know when to forward natively to non-LISP sites. Well when an ITR get= s a cache miss, it could send the packet natively as well as send a rate-li= mited Map-Request. We do implement very short-lived data-caches so we can d= o aggressive rate-limiting. If a Map-Reply is returned, you know the destin= ation is a LISP site and you cache the positive entry. If nothing comes bac= k, you continue to forward natively. As I said, this puts more Map-Request = load on the mapping system.

I do not understand how this can be effect= ive. =A0If the ITR does not have a native Locator address for the payload a= ddress family, and the site is relying upon LISP, there won't be a way = for packets to even reach the "native Internet" for some alternat= e forwarding to the destination.


--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr= Network Operator=A0 /=A0 Innovative Network Concepts
--0016e64079284b89e204a891954f-- From jsw@inconcepts.biz Thu Jul 21 03:26:56 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BA321F86D8 for ; Thu, 21 Jul 2011 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B91goAq+RMDg for ; Thu, 21 Jul 2011 03:26:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78DA621F8586 for ; Thu, 21 Jul 2011 03:26:55 -0700 (PDT) Received: by vws12 with SMTP id 12so979349vws.31 for ; Thu, 21 Jul 2011 03:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.161 with SMTP id dh1mr72600vdc.177.1311244014911; Thu, 21 Jul 2011 03:26:54 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Thu, 21 Jul 2011 03:26:54 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: Date: Thu, 21 Jul 2011 06:26:54 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a8e56b9027604a891c9e1 Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 10:26:56 -0000 --bcaec51a8e56b9027604a891c9e1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci wrote: > (1) At the ITR > I think this presumes that a malicious end-user in the Locator address space can't simply forge packets and pretend to be an ITR. It would also rely on most/all operators of ITRs to configure uRPF or BCP-38 at their site, which historically has been impossible to achieve for a large enough portion of the Internet to prevent large spoofed source attacks. > (2) At the PE router connecting the site's ITR to the service provider PE > The PE router may not have routing tables for the given address-family. Even if the PE did, to do uRPF on the inner-payload, it would encounter the same scaling limitations as xTRs. > (3) At the ETR > How can the ETR do uRPF without also being subject to the same mapping churn problem as an ITR? It must have access to enough state information to check all the packets flowing through it, so if under attack, it must have enough FIB to install many entries from the MS. Also another, different, problem is that if an ETR doing uRPF has routinely 20k flow cache entries, because around 20k sites are accessing the downstream hosts, but suddenly a DoS begins at a high rate, it will take some time for the FIB to become populated with enough of the address space for the uRPF checks to be successful on most legitimate traffic arriving from "new sites." The reason is, for example, if there are 500k total mappings possible and the FIB can punt and update at 20k/second, for around 25 seconds an initially high, and then decreasing toward zero, portion of new flows will be dropped because the limit of punts has been reached. TCP will simply retransmit but performance of the downstream hosts will appear to be affected temporarily. As more negative entries can be installed to do the uRPF failures without punting, the rate of successful punts, and mapping FIB installs, for "good" sources will increase. This assumes there is enough FIB. (4) At a firewall router anywhere in the path. > IMO this has the same scaling limitation as the ETR. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --bcaec51a8e56b9027604a891c9e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci = <dino@cisco.com&= gt; wrote:
(1) At the ITR

I think this presumes that a malicious end= -user in the Locator address space can't simply forge packets and prete= nd to be an ITR. =A0It would also rely on most/all operators of ITRs to con= figure uRPF or BCP-38 at their site, which historically has been impossible= to achieve for a large enough portion of the Internet to prevent large spo= ofed source attacks.
=A0
(2) At the PE router connecti= ng the site's ITR to the service provider PE

The PE router may not have routing tables = for the given address-family. =A0Even if the PE did, to do uRPF on the inne= r-payload, it would encounter the same scaling limitations as xTRs.
=A0
(3) At the ETR

How can the ETR do uRPF without also being= subject to the same mapping churn problem as an ITR? =A0It must have acces= s to enough state information to check all the packets flowing through it, = so if under attack, it must have enough FIB to install many entries from th= e MS.

Also another, different, problem is that if an ETR doin= g uRPF has routinely 20k flow cache entries, because around 20k sites are a= ccessing the downstream hosts, but suddenly a DoS begins at a high rate, it= will take some time for the FIB to become populated with enough of the add= ress space for the uRPF checks to be successful on most legitimate traffic = arriving from "new sites." =A0The reason is, for example, if ther= e are 500k total mappings possible and the FIB can punt and update at 20k/s= econd, for around 25 seconds an initially high, and then decreasing toward = zero, portion of new flows will be dropped because the limit of punts has b= een reached. =A0TCP will simply retransmit but performance of the downstrea= m hosts will appear to be affected temporarily. =A0As more negative entries= can be installed to do the uRPF failures without punting, the rate of succ= essful punts, and mapping FIB installs, for "good" sources will i= ncrease. =A0This assumes there is enough FIB.

(4) At a firewall router any= where in the path.

IMO this has the sam= e scaling limitation as the ETR.
=A0
--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operato= r=A0 /=A0 Innovative Network Concepts
--bcaec51a8e56b9027604a891c9e1-- From Fred.L.Templin@boeing.com Thu Jul 21 08:48:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37BE21F877B for ; Thu, 21 Jul 2011 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU3qN4PS4bZ1 for ; Thu, 21 Jul 2011 08:48:15 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC2321F86AD for ; Thu, 21 Jul 2011 08:48:15 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6LFm9V2023071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2011 10:48:10 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6LFm9dD024611; Thu, 21 Jul 2011 08:48:09 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6LFm8Le024589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Jul 2011 08:48:09 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 21 Jul 2011 08:48:08 -0700 From: "Templin, Fred L" To: Jeff Wheeler Date: Thu, 21 Jul 2011 08:48:07 -0700 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxHNHfYoXlQ7zw4TD+YSE1AtyAOXgAh2FgQ Message-ID: References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:48:15 -0000 Hi Jeff,=20 > -----Original Message----- > From: Jeff Wheeler [mailto:jsw@inconcepts.biz]=20 > Sent: Wednesday, July 20, 2011 4:27 PM > To: Templin, Fred L > Cc: lisp@ietf.org > Subject: Re: [lisp] Fwd: Anybody can participate in the IETF=20 > (Was: Why is IPv6 broken?) >=20 > On Wed, Jul 20, 2011 at 5:51 PM, Templin, Fred L > wrote: > > I would be interested in your assessment of whether > > this caching issue applies also to IRON [RFC6179]. >=20 > I am not familiar with this work, and have only had a chance to skim > RFC6179. However, it appears to me that IRON does not direct the IRON > routers specifically to employ a cache, and indeed within each VPC, > the routing protocol used to manage the VP may be different from > others. So unlike LISP, which essentially requires the use of > cache-based FIB and the LISP MS protocol for routing state, a VPC > could choose to implement whatever they decide is smart for their own > application, or purchase equipment from a vendor who has implemented > what they feel is adequate. That is right. IRON is a hybrid routing/mapping system where standard Internet routing is used outside of the VPC overlay network, and a combination of routing/mapping is used inside of the VPC overlay network. Standard Internet routing is used between the VPC's relays and servers, and mappings show up in a client's FIB based on Redirects received from a trusted Server. If the mapping cache overflows, a more-specific route may be lost and a default route will be used instead. But, there will always be a useable route. > > I think it probably doesn't, because the IRON tunnel > > endpoints are not trying to hold all recently heard > > from correspondents in their cache, but I would be > > interested to hear what you think. >=20 > The problems I have been discussing with LISP are not related to > payload buffering, but to routing state. >=20 > One thing that jumps out at me about IRON, and keep in mind I have > only skimmed the RFC and I may be incorrect, but I believe that, > within a given VPC, malicious host H might send encapsulated packets > to server A, when in fact server C is responsible for routing for > those packets' destination EP. I believe IRON specifies that server A > would do two things in this scenario; 1) forward the packet to server > C, and 2) send a redirect back to the Locator address in the > outer-header (probably not host H's address, but a forged/spoofed > address.) This would allow the use of server A for reflecting an > attack against server C, and also, some other Locator would receive > redirect messages at whatever rate they are generated. This seems > less than ideal. I think you are right based on what is actually written in RFC6179, but my understanding of the model has advanced since that document was written to where I now believe that there must be strong authentication between the client and server so that the server can't be manipulated into causing an anonymous reflection attack. I have written about the client/server authentication in 'draft-templin-ironmike'. The redirection scenario you are describing also won't happen in the new model I have in mind. I think what would clear this and other things up is an RFC6179(bis), which is on my todo list to initiate. Thanks - Fred fred.l.templin@boeing.com > --=20 > Jeff S Wheeler > Sr Network Operator=A0 /=A0 Innovative Network Concepts > = From jsw@inconcepts.biz Thu Jul 21 10:00:57 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE53F21F8757 for ; Thu, 21 Jul 2011 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ2qpnfINZnw for ; Thu, 21 Jul 2011 10:00:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 065CC21F874C for ; Thu, 21 Jul 2011 10:00:56 -0700 (PDT) Received: by vws12 with SMTP id 12so1291622vws.31 for ; Thu, 21 Jul 2011 10:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.138 with SMTP id w10mr555279vdt.43.1311267656423; Thu, 21 Jul 2011 10:00:56 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Thu, 21 Jul 2011 10:00:56 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> Date: Thu, 21 Jul 2011 13:00:56 -0400 Message-ID: From: Jeff Wheeler To: "Templin, Fred L" , lisp@ietf.org Content-Type: multipart/alternative; boundary=20cf307f37e4ddd84704a8974a96 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:00:57 -0000 --20cf307f37e4ddd84704a8974a96 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred L wrote: > > to where I now believe that there must be strong > authentication between the client and server so > that the server can't be manipulated into causing > an anonymous reflection attack. I have written > about the client/server authentication in > 'draft-templin-ironmike'. The redirection > scenario you are describing also won't happen in > the new model I have in mind. > Is it possible to do this without requiring the data-plane to have computationally expensive encryption capabilities? A shared-secret plus outer-header CRC could probably accomplish this without a big leap from what is done for forwarding ordinary IP traffic. This is not cryptographically strong like more expensive hashes or RSA, but would not limit IRON to being used for lower-throughput applications. I am sure there are better ideas out there than to just use a simple CRC, but this is an example I can imagine which could be made to work without dramatically more complexity or power/silicon requirements for data-plane. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --20cf307f37e4ddd84704a8974a96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred = L <Fred.L= .Templin@boeing.com> wrote:
to where I now believe that there must be strong
authentication between the client and server so
that the server can't be manipulated into causing
an anonymous reflection attack. I have written
about the client/server authentication in
'draft-templin-ironmike'. The redirection
scenario you are describing also won't happen in
the new model I have in mind.

Is it po= ssible to do this without requiring the data-plane to have computationally = expensive encryption capabilities? =A0A shared-secret plus outer-header CRC= could probably accomplish this without a big leap from what is done for fo= rwarding ordinary IP traffic. =A0This is not cryptographically strong like = more expensive hashes or RSA, but would not limit IRON to being used for lo= wer-throughput applications. =A0I am sure there are better ideas out there = than to just use a simple CRC, but this is an example I can imagine which c= ould be made to work without dramatically more complexity or power/silicon = requirements for data-plane.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator=A0 /=A0 Innov= ative Network Concepts

--20cf307f37e4ddd84704a8974a96-- From Fred.L.Templin@boeing.com Thu Jul 21 10:15:37 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C969F21F8764 for ; Thu, 21 Jul 2011 10:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfTPw-j-tIN1 for ; Thu, 21 Jul 2011 10:15:37 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3357021F8760 for ; Thu, 21 Jul 2011 10:15:37 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6LHFZHE025519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2011 10:15:36 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6LHFZ0I016273; Thu, 21 Jul 2011 12:15:35 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6LHEebw014100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Jul 2011 12:15:35 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 21 Jul 2011 10:15:05 -0700 From: "Templin, Fred L" To: Jeff Wheeler , "lisp@ietf.org" Date: Thu, 21 Jul 2011 10:15:04 -0700 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxHx8LuEnoST9t6RxSzTqxIhkHYZAAAWRZA Message-ID: References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C76DE4559XCHNW01Vnwnos_" MIME-Version: 1.0 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:15:37 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C76DE4559XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff, Actually, when using IPsec tunnels between the client and server is too heavywieght, IRON uses SEAL encapsulation which has a 48-bit nonce that is a shared secret between the tunnel endpoints. This provides a deterrent against off-path attacks, but cannot protect against MITM attacks. I have gone over and over again in my mind as to whether the SEAL nonce is an adequate protection, and for what use cases. I could sure use some help in understanding the security implications. Thanks - Fred ________________________________ From: Jeff Wheeler [mailto:jsw@inconcepts.biz] Sent: Thursday, July 21, 2011 10:01 AM To: Templin, Fred L; lisp@ietf.org Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is I= Pv6 broken?) On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred L > wrote: to where I now believe that there must be strong authentication between the client and server so that the server can't be manipulated into causing an anonymous reflection attack. I have written about the client/server authentication in 'draft-templin-ironmike'. The redirection scenario you are describing also won't happen in the new model I have in mind. Is it possible to do this without requiring the data-plane to have computat= ionally expensive encryption capabilities? A shared-secret plus outer-head= er CRC could probably accomplish this without a big leap from what is done = for forwarding ordinary IP traffic. This is not cryptographically strong l= ike more expensive hashes or RSA, but would not limit IRON to being used fo= r lower-throughput applications. I am sure there are better ideas out ther= e than to just use a simple CRC, but this is an example I can imagine which= could be made to work without dramatically more complexity or power/silico= n requirements for data-plane. -- Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts --_000_E1829B60731D1740BB7A0626B4FAF0A65C76DE4559XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
 
Actually, when using IPsec tunnels between the cli= ent and=20 server
is too heavywieght, IRON uses SEAL encapsulation w= hich has=20 a
48-bit nonce that is a shared secret between the t= unnel=20 endpoints.
This provides a deterrent against off-path attacks, but canno= t=20 protect
against MITM attacks.
 
I have gone over and over again in my mind as to w= hether=20 the SEAL
nonce is an adequate protection, and for what use = cases. I=20 could
sure use some help in understanding the security=20 implications.
 
Thanks - Fred
 

From: Jeff Wheeler [mailto:jsw@inconc= epts.biz]=20
Sent: Thursday, July 21, 2011 10:01 AM
To: Templin, = Fred=20 L; lisp@ietf.org
Subject: Re: [lisp] Fwd: Anybody can participa= te in=20 the IETF (Was: Why is IPv6 broken?)

On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred = L <Fred.L.Templin@boeing.com&g= t;=20 wrote:
to=20 where I now believe that there must be strong
authentication between= the=20 client and server so
that the server can't be manipulated into=20 causing
an anonymous reflection attack. I have written
about the= =20 client/server authentication in
'draft-templin-ironmike'. The=20 redirection
scenario you are describing also won't happen in
the = new=20 model I have in mind.

Is it possible to do this without requiring the data-plane= to=20 have computationally expensive encryption capabilities?  A shared-se= cret=20 plus outer-header CRC could probably accomplish this without a big leap f= rom=20 what is done for forwarding ordinary IP traffic.  This is not=20 cryptographically strong like more expensive hashes or RSA, but would not= =20 limit IRON to being used for lower-throughput applications.  I am su= re=20 there are better ideas out there than to just use a simple CRC, but this = is an=20 example I can imagine which could be made to work without dramatically mo= re=20 complexity or power/silicon requirements for data-plane.
<= BR>--=20
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator  /=  =20 Innovative Network Concepts

--_000_E1829B60731D1740BB7A0626B4FAF0A65C76DE4559XCHNW01Vnwnos_-- From dino@cisco.com Thu Jul 21 17:31:32 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D0421F855D for ; Thu, 21 Jul 2011 17:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=-2.764, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcJLZGxl9MCW for ; Thu, 21 Jul 2011 17:31:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A97A221F855B for ; Thu, 21 Jul 2011 17:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2761; q=dns/txt; s=iport; t=1311294691; x=1312504291; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=VL5JVeky2TtcWufRK19+zoiR9kZa6UfFT8h2qvXaogM=; b=ZdkdT9UCETVNr/I+9VPMhzO1R33nYU64jq+IDbzdhg0CxFwwtYIcHJ9h dfAf2nIR43zUyjvWMaE2sW37zOj0O4xKGpVjc10FKR4MX+QsK/r4mEWtG UJ9atMfYZmIjbNp/rxN5BcFIgRt7E9ihZhcdqCnHizXWzgGuRx7OgSfsF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHzDKE6rRDoH/2dsb2JhbABTp0F3iHyeUZ4ShWBfBIdVixmFB4t3 X-IronPort-AV: E=Sophos;i="4.67,244,1309737600"; d="scan'208";a="5308755" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jul 2011 00:31:31 +0000 Received: from [192.168.1.6] ([10.21.75.52]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6M0VUWY023096; Fri, 22 Jul 2011 00:31:30 GMT Message-Id: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> From: Dino Farinacci To: Jeff Wheeler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jul 2011 17:31:29 -0700 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 00:31:32 -0000 > On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci > wrote: > (1) At the ITR > > I think this presumes that a malicious end-user in the Locator > address space can't simply forge packets and pretend to be an ITR. > It would also rely on most/all operators of ITRs to configure uRPF > or BCP-38 at their site, which historically has been impossible to > achieve for a large enough portion of the Internet to prevent large > spoofed source attacks. No, you build it into the implementation. > (2) At the PE router connecting the site's ITR to the service > provider PE > > The PE router may not have routing tables for the given address- > family. Even if the PE did, to do uRPF on the inner-payload, it > would encounter the same scaling limitations as xTRs. Right, like I said doing it at the ITR is the best place. > (3) At the ETR > > How can the ETR do uRPF without also being subject to the same > mapping churn problem as an ITR? It must have access to enough > state information to check all the packets flowing through it, so if > under attack, it must have enough FIB to install many entries from > the MS. I said don't solve the problem here. > Also another, different, problem is that if an ETR doing uRPF has > routinely 20k flow cache entries, because around 20k sites are > accessing the downstream hosts, but suddenly a DoS begins at a high > rate, it will take some time for the FIB to become populated with > enough of the address space for the uRPF checks to be successful on > most legitimate traffic arriving from "new sites." The reason is, > for example, if there are 500k total mappings possible and the FIB > can punt and update at 20k/second, for around 25 seconds an > initially high, and then decreasing toward zero, portion of new > flows will be dropped because the limit of punts has been reached. > TCP will simply retransmit but performance of the downstream hosts > will appear to be affected temporarily. As more negative entries > can be installed to do the uRPF failures without punting, the rate > of successful punts, and mapping FIB installs, for "good" sources > will increase. This assumes there is enough FIB. > > (4) At a firewall router anywhere in the path. > > IMO this has the same scaling limitation as the ETR. I gave you alternatives and told you that (1) is the best place. So you are agreeing with me for (2) through (4). Dino > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Thu Jul 21 18:09:04 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5623021F8A1A for ; Thu, 21 Jul 2011 18:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.779 X-Spam-Level: X-Spam-Status: No, score=-4.779 tagged_above=-999 required=5 tests=[AWL=-2.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdKcOT5Tf3lC for ; Thu, 21 Jul 2011 18:09:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 59E5021F89CC for ; Thu, 21 Jul 2011 18:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=4506; q=dns/txt; s=iport; t=1311296943; x=1312506543; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=0BSXFWXWBTr7uXbRBj6UVXtp9nLydMzf2/6LKoVvvzE=; b=RktoboBp3SMWTli4ipP+uK05XKb+jHkJDHZQ9J8V6jdUFbYVvRtIQAYS /cR+w+tIiAMUWXb1h0q/BwgG0VgUmi4s+9aTLcf6SbdufTvAqB8AL29N/ HkScJWyi/573z96yvexw1kvJ7PZXLrxhnJ634GxJHkdyah9kLsztTuF4m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIrNKE6rRDoH/2dsb2JhbABTp0F3iHyeW54WhWBfBIdVixmFB4t3 X-IronPort-AV: E=Sophos;i="4.67,244,1309737600"; d="scan'208";a="5314157" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2011 01:08:49 +0000 Received: from [192.168.1.6] ([10.21.75.52]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6M18nvf011729; Fri, 22 Jul 2011 01:08:49 GMT Message-Id: <45F14A60-69F8-4E72-959D-9AB72D17DE7D@cisco.com> From: Dino Farinacci To: Jeff Wheeler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 21 Jul 2011 18:08:48 -0700 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] FIB compression as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 01:09:04 -0000 > On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci > wrote: > Jeff mentioned for (1) to have the mapping system return a coarse > negative prefix with positive ones which punch holes in negative map- > replies. This will be quite hard since the sender of the negative > Map-Reply may not know all positive entries (since they are spread > around and stored in other map-servers). But the map-server could > infer based on looking at the ALT to find positive entries. So some > research can be done on this idea to see if is tractable. > > It would be possible to install shorter negative plus one or more > longer positives that are not complete mappings, but "next-hop ms- > resolve," which would discard packets to the shorter negative but > still be able to punt and do MS query for the possibly-positive part > of the address space. Yes, that could be done but again, we could create more entries then we wanted to. > If I was the implementer, I would probably then keep count in my > Trie to know when a particular branch of the address space cache > contains mostly negative entries, which would indicate opportunities > for on-demand "compression." Yes, we can do that as well. > Another way to tackle (1) is to have the ITR look at the more- > specific negative prefixes to see if they can be combined into a > fewer number of more coarse prefixes using localized prefix > compression. If exact compression can be done, then do it (meaning > their are no positive holes in the compressed aggregate). If there > are holes created, they *could be mitigated* if you already have a > positive cache entry stored because you previously have encapsulated > to the site. But you can't always depend on this ordering to make it > reliable. > > I do not understand how this can be beneficial if the MS currently > sends negative replies that are the shortest possible prefixes which > do not overlap any possible positive mapping. Keep in mind that my > understanding of the control-plane remains limited, specifically I > am not familiar with how much state is available from the local MS > vs what must be retrieved from distant MS. I need to do some > homework in this area. This is exactly what you suggested above. There are cases where a map- server returns a negative map-reply for a configured EID-prefix but has not been registered by the site. > As for (2), we could say, we'll make a tradeoff by saving the cache > at the expense of more load on the mapping system. Well the mapping > system (like DNS) has to be provisioned and capacity planned to > handle load for scaling reasons. So it should also be able to handle > DoS load too. And if it can't, then the DoS load gets dropped (that > is the good news). But with every DoS load that gets dropped there > is good load that loses too. So take this with a grain of salt. > > But if the ITRs only stored positive cache entries, one might think > we would not know when to forward natively to non-LISP sites. Well > when an ITR gets a cache miss, it could send the packet natively as > well as send a rate-limited Map-Request. We do implement very short- > lived data-caches so we can do aggressive rate-limiting. If a Map- > Reply is returned, you know the destination is a LISP site and you > cache the positive entry. If nothing comes back, you continue to > forward natively. As I said, this puts more Map-Request load on the > mapping system. > > I do not understand how this can be effective. If the ITR does not > have a native Locator address for the payload address family, and > the site is relying upon LISP, there won't be a way for packets to > even reach the "native Internet" for some alternate forwarding to > the destination. A "native locator" as you termed it is just a FIB route with a next- hop. If the destination is non-LISP, the packet flows natively to the site as it does today. If the destination is a LISP site (and the ITR does not have a Map-Reply returned yet so it cannot encapsulate), the ITR will forward towards a PITR which will encapsulate to the site. Dino > > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From terry.manderson@icann.org Thu Jul 21 19:38:52 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968C221F8639 for ; Thu, 21 Jul 2011 19:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lbe3pUKc0IY2 for ; Thu, 21 Jul 2011 19:38:52 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4299521F8620 for ; Thu, 21 Jul 2011 19:38:52 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 21 Jul 2011 19:38:51 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 21 Jul 2011 19:38:50 -0700 Thread-Topic: presentations for Monday Thread-Index: AcxIGHz4oagj+OZkEkGE7KNIUMNMNA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] presentations for Monday X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 02:38:52 -0000 All, LISP @IETF81 is on Monday. The current agenda can be found here: http://tools.ietf.org/wg/lisp/agenda Given I am going to be spending the next day and a bit in transit, presenters please email me your slide ware by Monday morning 10am Email me for changes and omissions ASAP. Cheers Terry From jsw@inconcepts.biz Fri Jul 22 07:28:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA4121F854D for ; Fri, 22 Jul 2011 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krWAloXBrhsf for ; Fri, 22 Jul 2011 07:28:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32EF621F8532 for ; Fri, 22 Jul 2011 07:28:58 -0700 (PDT) Received: by vws12 with SMTP id 12so2105437vws.31 for ; Fri, 22 Jul 2011 07:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.138 with SMTP id w10mr1650621vdt.43.1311344937536; Fri, 22 Jul 2011 07:28:57 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Fri, 22 Jul 2011 07:28:57 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> Date: Fri, 22 Jul 2011 10:28:57 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=20cf307f37e42e0d9604a8a9494f Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:28:58 -0000 --20cf307f37e42e0d9604a8a9494f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 21, 2011 at 8:31 PM, Dino Farinacci wrote: > On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci wrote: >> (1) At the ITR >> >> I think this presumes that a malicious end-user in the Locator address >> space can't simply forge packets and pretend to be an ITR. It would also >> rely on most/all operators of ITRs to configure uRPF or BCP-38 at their >> site, which historically has been impossible to achieve for a large enough >> portion of the Internet to prevent large spoofed source attacks. >> > > No, you build it into the implementation. How will the ETRs know if packets have come from a "real ITR" that follows this part of the specification, or if the packets came from malicious hosts masquerading as ITRs? It is obvious that an attacker will simply originate encapsulated packets from machines with native Internet access, so they appear to come from ITRs, but really come from his tool that does not obey this rule. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --20cf307f37e42e0d9604a8a9494f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 21, 2011 at 8:31 PM, Dino Farinacci = <dino@cisco.com&= gt; wrote:
On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci <dino@cisco.com> wrote:
(1) At the ITR

I think this presumes that a malicious end-user in the Locator address spac= e can't simply forge packets and pretend to be an ITR. =A0It would also= rely on most/all operators of ITRs to configure uRPF or BCP-38 at their si= te, which historically has been impossible to achieve for a large enough po= rtion of the Internet to prevent large spoofed source attacks.

No, you build it into the implementation.

= How will the ETRs know if packets have come from a "real ITR" tha= t follows this part of the specification, or if the packets came from malic= ious hosts masquerading as ITRs? =A0It is obvious that an attacker will sim= ply originate encapsulated packets from machines with native Internet acces= s, so they appear to come from ITRs, but really come from his tool that doe= s not obey this rule.

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator=A0 /=A0 Innov= ative Network Concepts
--20cf307f37e42e0d9604a8a9494f-- From dino@cisco.com Fri Jul 22 09:04:25 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BD21F8B48 for ; Fri, 22 Jul 2011 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[AWL=-2.443, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBug7+sWMgtS for ; Fri, 22 Jul 2011 09:04:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 98F1021F8B16 for ; Fri, 22 Jul 2011 09:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2058; q=dns/txt; s=iport; t=1311350664; x=1312560264; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=3OFld18sJg2cHSGnnqkxHJqzW2lj8yZpy/76eIhlNx0=; b=QWWiGaxzaswiyybGagjI5+yhFTUDAUrqakYeClLBfByBSHxch+FkgLll UaCDkWDJ4dE7hZuJE32MMvAsWUzqqh/Xe9HwpL2QtlYczdJHZMR/1nimk d1maWFcw8iBDmIxG9rtSYAHxu8QdDBbZWAPzVEzHNJlpCaGK4qqt3JjOi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEifKU6rRDoH/2dsb2JhbABTp0d3iHwEnE6eLoVgXwSHVYsZhQeLeA X-IronPort-AV: E=Sophos;i="4.67,248,1309737600"; d="scan'208";a="5539365" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2011 16:04:07 +0000 Received: from [192.168.1.6] (sjc-vpn6-1503.cisco.com [10.21.125.223]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6MG47Av011471; Fri, 22 Jul 2011 16:04:07 GMT Message-Id: <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> From: Dino Farinacci To: Jeff Wheeler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jul 2011 09:04:07 -0700 References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:04:25 -0000 > On Thu, Jul 21, 2011 at 8:31 PM, Dino Farinacci > wrote: > On Thu, Jul 21, 2011 at 5:13 AM, Dino Farinacci > wrote: > (1) At the ITR > > I think this presumes that a malicious end-user in the Locator > address space can't simply forge packets and pretend to be an ITR. > It would also rely on most/all operators of ITRs to configure uRPF > or BCP-38 at their site, which historically has been impossible to > achieve for a large enough portion of the Internet to prevent large > spoofed source attacks. > > No, you build it into the implementation. > > How will the ETRs know if packets have come from a "real ITR" that > follows this part of the specification, or if the packets came from > malicious hosts masquerading as ITRs? It is obvious that an > attacker will So we are thinking of putting some data-plane authentication in which we can talk about later. This is work in progress and nothing has been published yet. > simply originate encapsulated packets from machines with native > Internet access, so they appear to come from ITRs, but really come > from his tool that does not obey this rule. This is where you need a firewall (at the access SP) to do mapping database lookups to verify the (source-EID, source-RLOC) binding. Also, we do have data-plane gleaning in an ETR specified in the spec. So the packet could be accepted in an ETR, source-EID and RLOC gleaned, and when the SYN-ACK is returned, the map-cache can be verified. That way, you put the mapping database lookup in the place where it is already being done for other reasons. This is a tough problem. We will probably discuss this next week. Luigi has an agenda slot to discuss LISP related security threats. Dino > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jsw@inconcepts.biz Fri Jul 22 09:42:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8421F8B0A for ; Fri, 22 Jul 2011 09:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEI8ef58Mv-R for ; Fri, 22 Jul 2011 09:42:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A452921F8B00 for ; Fri, 22 Jul 2011 09:42:15 -0700 (PDT) Received: by vws12 with SMTP id 12so2226227vws.31 for ; Fri, 22 Jul 2011 09:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.47 with SMTP id r15mr1761689vdf.110.1311352935046; Fri, 22 Jul 2011 09:42:15 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Fri, 22 Jul 2011 09:42:14 -0700 (PDT) X-Originating-IP: [74.133.147.213] In-Reply-To: <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> Date: Fri, 22 Jul 2011 12:42:14 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=20cf307f37b8de5d7304a8ab2507 Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:42:16 -0000 --20cf307f37b8de5d7304a8ab2507 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 22, 2011 at 12:04 PM, Dino Farinacci wrote: > So we are thinking of putting some data-plane authentication in which we >> can talk about later. This is work in progress and nothing has been >> published yet. > > How might this work without the ETR being required to do look-ups in order to perform the authentication check? > This is where you need a firewall (at the access SP) to do mapping database > lookups to verify the (source-EID, source-RLOC) binding. > I'm not clear on what you are suggesting. Certainly it will not be the case that "native Internet" service providers will gain the ability to peek into LISP inner-headers and do any kind of check. > Also, we do have data-plane gleaning in an ETR specified in the spec. So > the packet could be accepted in an ETR, source-EID and RLOC gleaned, and > when the SYN-ACK is returned, the map-cache can be verified. That way, you > put the mapping database lookup in the place where it is already being done > for other reasons. > You are describing a case where the ETR is also the ITR? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --20cf307f37b8de5d7304a8ab2507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 22, 2011 at 12:04 PM, Dino Farinacci= <dino@cisco.com= > wrote:
So we are thinking of putt= ing some data-plane authentication in which we can talk about later. This i= s work in progress and nothing has been published yet.

How might this work without the ETR = being required to do look-ups in order to perform the authentication check?=
=A0
This is where you need a firewall (at the access SP) to d= o mapping database lookups to verify the (source-EID, source-RLOC) binding.=

I'm not clear on what you are su= ggesting. =A0Certainly it will not be the case that "native Internet&q= uot; service providers will gain the ability to peek into LISP inner-header= s and do any kind of check.
=A0
Also, we do have data-plane gleaning in an ETR specified in the spec. So th= e packet could be accepted in an ETR, source-EID and RLOC gleaned, and when= the SYN-ACK is returned, the map-cache can be verified. That way, you put = the mapping database lookup in the place where it is already being done for= other reasons.

You are describing a case where the ETR i= s also the ITR?

--
Jeff S Wheeler <jsw@inconcepts.biz>
S= r Network Operator=A0 /=A0 Innovative Network Concepts
--20cf307f37b8de5d7304a8ab2507-- From rbonica@juniper.net Fri Jul 22 12:49:58 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEFB21F8B50 for ; Fri, 22 Jul 2011 12:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucc6KrlcKCDV for ; Fri, 22 Jul 2011 12:49:58 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B28BD21F8B4F for ; Fri, 22 Jul 2011 12:49:57 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTinUZUy7/Pn0WjFIwoyXjgTpKCjEIKR0@postini.com; Fri, 22 Jul 2011 12:49:57 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Jul 2011 12:48:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 22 Jul 2011 15:48:04 -0400 From: Ronald Bonica To: "lisp@ietf.org" Date: Fri, 22 Jul 2011 15:48:02 -0400 Thread-Topic: gleaned mappings Thread-Index: AcxIqER8v3KqVyHvRzydh6UpdAWRhA== Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:49:58 -0000 Folks, In Section 4.1 of the draft-ietf-lisp you say: In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner header source IP address) to the source RLOC (outer header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details. Has anyone thought through the security implications and possible unexpecte= d side effects of these "gleaned" mappings? Ron From rbonica@juniper.net Fri Jul 22 13:47:19 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0DF21F8AF1 for ; Fri, 22 Jul 2011 13:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSAJszZbjX5e for ; Fri, 22 Jul 2011 13:47:18 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D547E21F8AD8 for ; Fri, 22 Jul 2011 13:47:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTinh0knaV8cfsQwGDDyv6pw5Tg2nYO+s@postini.com; Fri, 22 Jul 2011 13:47:18 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 22 Jul 2011 13:47:01 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 22 Jul 2011 16:47:00 -0400 From: Ronald Bonica To: Ronald Bonica , "Joel M. Halpern" Date: Fri, 22 Jul 2011 16:46:58 -0400 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxHD3oLPMYhdeCmRP+wOGt6KlOf+AACBz6AAGUaOPA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CAC4@EMBX01-WF.jnpr.net> References: <20110719202525.04B0818C1A8@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F40F26EE@EMBX01-WF.jnpr.net> <4E2716CD.2030101@joelhalpern.com> <13205C286662DE4387D9AF3AC30EF456D3F40F2AB4@EMBX01-WF.jnpr.net> <4E27260F.5040401@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , Noel Chiappa Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 20:47:19 -0000 Folks, The following is the text that I promised. Ron 6.7 Cache Exhaustion LISP works best when sufficient memory is allocated to the EID-to-RLOC cach= e. In this case, whenever a new EID-to-RLOC mapping is required, it can be = added to the cache without removing another useful mapping in order to make= room. Storage requirements for the EID-to-RLOC cache are determined by the= data plane. Because data plane behavior is unpredictable, it is very diffi= cult to determine how much memory needs to be allocated to the EID-to-RLOC = cache. Therefore, implementations must behave reasonably well during period= s of cache exhaustion. The following are characteristics of a well-behaved implementation: - minimizes packet loss - distributes packet loss across flows in a predictable (and possibly) cont= rollable manner - does not oversubscribe control plane resources This memo does not specify cache management algorithms to be executed durin= g periods of cache exhaustion. This is left as an exercise for implementers= , and a method through which they can differentiate their implementations f= rom one another. At the time of publication, several algorithms have been d= iscussed, but none has been proven to work better than the others under all= conditions. > -----Original Message----- > From: Ronald Bonica > Sent: Wednesday, July 20, 2011 4:00 PM > To: 'Joel M. Halpern' > Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > Subject: RE: [lisp] Fwd: Anybody can participate in the IETF (Was: Why > is IPv6 broken?) >=20 > I will generate some text late this week. >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Wednesday, July 20, 2011 3:02 PM > > To: Ronald Bonica > > Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > > Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: > Why > > is IPv6 broken?) > > > > There already is warning text on this in the document. > > If we are going to add yet more warning to the documents we are > > currently working on, I would want to see specific proposed text with > a > > specific placement. > > > > Thank you, > > Joel > > > > On 7/20/2011 2:45 PM, Ronald Bonica wrote: > > > Joel, > > > > > > I am fine with Jeff's proposal. We can simply note that "there is a > > sharp edge here, and that no strategy has > > > been demonstrated to address all corner cases." When the issue has > > been adequately addressed, we can issue a bis document that does not > > include the caveat. > > > > > > Ron > > > > > > > > >> -----Original Message----- > > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > >> Sent: Wednesday, July 20, 2011 1:56 PM > > >> To: Ronald Bonica > > >> Cc: Noel Chiappa; jsw@inconcepts.biz; lisp@ietf.org > > >> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: > > Why > > >> is IPv6 broken?) > > >> > > >> Let me suggest a different phrasing Ron... > > >> It would seem reasonable to include discussion of this issue in a > > >> document. However, I do not see that it needs to be in the base > > specs > > >> at this stage of the game. A separate additional work item, if we > > have > > >> folks willing and interested in doing so, seems sensible. > > >> > > >> Yours, > > >> Joel > > >> > > >> On 7/20/2011 12:07 PM, Ronald Bonica wrote: > > >>>> One can easily imagine all sorts of ways to partition the cache, > > >> other > > >>>> than the > > >>>> one I suggested (which was to separate out highly-used mappings > > from > > >>>> new ones), > > >>>> if that proves to be not good enough. E.g. one could _also_ have > > >> code > > >>>> so that > > >>>> no individual client machine (i.e. source) can be the source of > > more > > >>>> than N% of > > >>>> the mappings, so that when a 'request' for the N+1th mapping > > arrives > > >>>> from that > > >>>> source, one of its oldest/least-used mappings gets evicted. Etc, > > >> etc, > > >>>> etc. > > >>>> > > >>>> It has been suggested that this might be a value-added > > >> differentiator > > >>>> for > > >>>> vendors, in fact - whose cache is most resistant to DoS? > > >>>> > > >>> > > >>> > > >>> Noel, > > >>> > > >>> At the risk of repeating myself, I think that the cache > > partitioning > > >> strategy should be spelled out in the specification. If we specify > > it, > > >> the strategy will benefit from wide review. > > >>> > > >>> If we don't specify a strategy, the specification should at least > > >> point out that there is a sharp edge here, and that no strategy > has > > >> been demonstrated to address all corner cases. > > >>> > > >>> > Ron > > >>> > > >>> _______________________________________________ > > >>> lisp mailing list > > >>> lisp@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/lisp > > >>> > > > From dino@cisco.com Fri Jul 22 14:46:50 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AC121F88A6 for ; Fri, 22 Jul 2011 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Nqp6TJ7Oy6 for ; Fri, 22 Jul 2011 14:46:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A35EF21F8AA8 for ; Fri, 22 Jul 2011 14:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1205; q=dns/txt; s=iport; t=1311371206; x=1312580806; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ae9sAhOg2WndYe6jDXuAkEBCIZmp5TC+udk9o7Aek4Q=; b=DOMY396ipBKLAGr9E0eWccoqEOOb94+ySuYkfoQsbB5BXTAoIwcltjgd FXEN6dRpH2OMzQq1b3OpKioEBPlpeolsa3GwGT7/mjh+aPOA0St/5Is9t hzZ3TT9TemAHEWu3rXQgVEml6tMS7FxZaJi2aNY6BLC2s+vCi8epNgbVN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA3vKU6rRDoI/2dsb2JhbABTp0x3iHwEnUmeIoVgXwSHVYsZhQeLeA X-IronPort-AV: E=Sophos;i="4.67,249,1309737600"; d="scan'208";a="5634131" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2011 21:46:46 +0000 Received: from [172.16.31.204] (sjc-vpn5-415.cisco.com [10.21.89.159]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6MLkjLp027243; Fri, 22 Jul 2011 21:46:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> Date: Fri, 22 Jul 2011 14:46:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Cc: "lisp@ietf.org" Subject: Re: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:46:51 -0000 The spec says that gleanings are verified by sending a Map-Request to = the mapping database system. Dino On Jul 22, 2011, at 12:48 PM, Ronald Bonica wrote: > Folks, >=20 > In Section 4.1 of the draft-ietf-lisp you say: >=20 > In order to defer the need for a mapping lookup in the reverse > direction, an ETR MAY create a cache entry that maps the source EID > (inner header source IP address) to the source RLOC (outer header > source IP address) in a received LISP packet. Such a cache entry is > termed a "gleaned" mapping and only contains a single RLOC for the > EID in question. More complete information about additional RLOCs > SHOULD be verified by sending a LISP Map-Request for that EID. Both > ITR and the ETR may also influence the decision the other makes in > selecting an RLOC. See Section 6 for more details. >=20 > Has anyone thought through the security implications and possible = unexpected side effects of these "gleaned" mappings? >=20 > Ron >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Fri Jul 22 16:55:55 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73FF21F8BFA for ; Fri, 22 Jul 2011 16:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3yOUM0h5d8Y for ; Fri, 22 Jul 2011 16:55:55 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 538A521F8C10 for ; Fri, 22 Jul 2011 16:55:55 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 00F5718C102; Fri, 22 Jul 2011 19:55:50 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110722235550.00F5718C102@mercury.lcs.mit.edu> Date: Fri, 22 Jul 2011 19:55:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:55:56 -0000 > From: Ronald Bonica > The following is the text that I promised. This sounds more like text that would address something we discussed several months ago (about how to size the cache)? I was expecting something that would focus a little more on DoS issues? Other than that, this text looks good. (Although "shown" feels better on my ear than "proven"... :-) Did you want to add references to the two papers that study/model cache performance issues? Noel From rbonica@juniper.net Sat Jul 23 07:12:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE7B21F874B for ; Sat, 23 Jul 2011 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuRFXM-OGGSc for ; Sat, 23 Jul 2011 07:12:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1A521F8743 for ; Sat, 23 Jul 2011 07:12:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTirWu8LtFTmIqxQcRko96INadcrEXHBU@postini.com; Sat, 23 Jul 2011 07:12:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 23 Jul 2011 07:10:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 23 Jul 2011 10:10:47 -0400 From: Ronald Bonica To: Noel Chiappa , "lisp@ietf.org" Date: Sat, 23 Jul 2011 10:10:44 -0400 Thread-Topic: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) Thread-Index: AcxIyud9McrCPOA5SNiY/DLiSNM4nQAdzztA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CCE6@EMBX01-WF.jnpr.net> References: <20110722235550.00F5718C102@mercury.lcs.mit.edu> In-Reply-To: <20110722235550.00F5718C102@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 14:12:14 -0000 Hi Noel, If you would like, I would be glad to write something about the DoS issues.= I suspect that this should go in the Security Considerations Section. Ron > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Friday, July 22, 2011 7:56 PM > To: lisp@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [lisp] Fwd: Anybody can participate in the IETF (Was: Why > is IPv6 broken?) >=20 > > From: Ronald Bonica >=20 > > The following is the text that I promised. >=20 > This sounds more like text that would address something we discussed > several > months ago (about how to size the cache)? I was expecting something > that would > focus a little more on DoS issues? >=20 > Other than that, this text looks good. (Although "shown" feels better > on my > ear than "proven"... :-) Did you want to add references to the two > papers > that study/model cache performance issues? >=20 > Noel From pfrejborg@gmail.com Sun Jul 24 01:33:01 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F2A21F89C2 for ; Sun, 24 Jul 2011 01:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtkG-IglMMBv for ; Sun, 24 Jul 2011 01:33:01 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8A21F8568 for ; Sun, 24 Jul 2011 01:33:00 -0700 (PDT) Received: by ewy19 with SMTP id 19so2422084ewy.31 for ; Sun, 24 Jul 2011 01:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hskQe22bxamOU+b7ho713Ve8VIhaCcmq+QP+5QkPZE8=; b=G8CnRI/zDMmyuBTNBMyF4UDRibH3eKXO2vvn8lxrYpzQ1Gn1rnovgGj4jICKSxD77g VH46QYXuB8C9eySqxpOC64hB+CQHu79skEuwkEtGgKWu2RpGBxcjN4q8BlDpApkukA0S VP4mW0u/dpsNkwO5uECoJRqVG7j1RMR/1zhy0= MIME-Version: 1.0 Received: by 10.213.26.17 with SMTP id b17mr1335536ebc.12.1311496378135; Sun, 24 Jul 2011 01:32:58 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Sun, 24 Jul 2011 01:32:58 -0700 (PDT) In-Reply-To: <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> Date: Sun, 24 Jul 2011 11:32:58 +0300 Message-ID: From: Patrick Frejborg To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 08:33:01 -0000 On Fri, Jul 22, 2011 at 7:04 PM, Dino Farinacci wrote: > Also, we do have data-plane gleaning in an ETR specified in the spec. So the > packet could be accepted in an ETR, source-EID and RLOC gleaned, and when > the SYN-ACK is returned, the map-cache can be verified. That way, you put > the mapping database lookup in the place where it is already being done for > other reasons. > > This is a tough problem. We will probably discuss this next week. Luigi has > an agenda slot to discuss LISP related security threats. > Dino, I don't know if this is an appropriate moment to step forward and say that this issue can be mitigated if you give up one of the LISP principles, i.e. no changes to endpoint stacks. If LISP also supports upgraded stacks then the enterprise have a choice - live with the risk of a potential DoS attack or mitigate it for the most important services by upgrading the stack at some endpoints. Of course, both endpoints of a session needs to be upgraded to mitigate the attack. By going after the stack we also gain a bunch of new incentives that enterprises should be interested in. Have a look at RFC 6306 but the new architecture that I'm thinking of is best described in http://www.cs.princeton.edu/research/techreps/TR-885-10 LISP is the first important step towards this kind of architecture - thus I don't want to lose it. Patrick From rbonica@juniper.net Sun Jul 24 07:21:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35F21F8540 for ; Sun, 24 Jul 2011 07:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSkDVVDqBs4m for ; Sun, 24 Jul 2011 07:21:09 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B6DE121F84DE for ; Sun, 24 Jul 2011 07:21:08 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTiwqVHBLYhmtgBE2eh04uiFH89HyqWgU@postini.com; Sun, 24 Jul 2011 07:21:09 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 24 Jul 2011 07:21:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 24 Jul 2011 10:21:07 -0400 From: Ronald Bonica To: Dino Farinacci Date: Sun, 24 Jul 2011 10:21:05 -0400 Thread-Topic: [lisp] gleaned mappings Thread-Index: AcxIuN0ZKkS7WsSuTiauF9G8tDJdzgBU+wtg Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CD4C@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 14:21:10 -0000 Is that a SHOULD or a MUST? From the text quoted below, I assume that it is= a SHOULD. Ron > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Friday, July 22, 2011 5:47 PM > To: Ronald Bonica > Cc: lisp@ietf.org > Subject: Re: [lisp] gleaned mappings >=20 > The spec says that gleanings are verified by sending a Map-Request to > the mapping database system. >=20 > Dino >=20 > On Jul 22, 2011, at 12:48 PM, Ronald Bonica wrote: >=20 > > Folks, > > > > In Section 4.1 of the draft-ietf-lisp you say: > > > > In order to defer the need for a mapping lookup in the reverse > > direction, an ETR MAY create a cache entry that maps the source EID > > (inner header source IP address) to the source RLOC (outer header > > source IP address) in a received LISP packet. Such a cache entry > is > > termed a "gleaned" mapping and only contains a single RLOC for the > > EID in question. More complete information about additional RLOCs > > SHOULD be verified by sending a LISP Map-Request for that EID. > Both > > ITR and the ETR may also influence the decision the other makes in > > selecting an RLOC. See Section 6 for more details. > > > > Has anyone thought through the security implications and possible > unexpected side effects of these "gleaned" mappings? > > > > Ron > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Sun Jul 24 11:07:07 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9E21F853A for ; Sun, 24 Jul 2011 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.394 X-Spam-Level: X-Spam-Status: No, score=-4.394 tagged_above=-999 required=5 tests=[AWL=-1.795, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcWcel6PC-xb for ; Sun, 24 Jul 2011 11:07:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1121F8532 for ; Sun, 24 Jul 2011 11:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1792; q=dns/txt; s=iport; t=1311530826; x=1312740426; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kV8usTd6mc0KqnySDH+X3Q568ZWXvke4YyeEca87jU0=; b=cJOT022uIXtQYOL9FogtDTSNbqONQEv6aXgmSKvfHdHXFe7r6Mlr6zzS azDGIvW/f7/CekKhOrubQEk1g2+3nUQ60Wkm4eODn/oq7iCHhrtFZJd0h zbkvAgtxsY8fGljwi5eQwcctsz3bVtO7tX38Gx8XSZBIVd/bN79TE/Zrm 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAADVeLE6rRDoH/2dsb2JhbAA1AQEBAQIBAQEBEQErOgsFBwUMDgMEAQEBMwcUGCMOCAcXJ5daj1J3iHwEn1SdKYVgXwSHVYsbhQeLeQ X-IronPort-AV: E=Sophos;i="4.67,257,1309737600"; d="scan'208";a="5925598" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2011 18:07:05 +0000 Received: from [10.21.118.158] ([10.21.118.158]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6OI6HWD007961; Sun, 24 Jul 2011 18:07:05 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431CD4C@EMBX01-WF.jnpr.net> Date: Sun, 24 Jul 2011 11:07:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F431CD4C@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1244.3) Cc: "lisp@ietf.org" Subject: Re: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 18:07:07 -0000 > Is that a SHOULD or a MUST? =46rom the text quoted below, I assume = that it is a SHOULD. It is a SHOULD because in controlled/trusted environments we don't want = to require the overhead of a verifying Map-Request. Dino >=20 > Ron >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Friday, July 22, 2011 5:47 PM >> To: Ronald Bonica >> Cc: lisp@ietf.org >> Subject: Re: [lisp] gleaned mappings >>=20 >> The spec says that gleanings are verified by sending a Map-Request to >> the mapping database system. >>=20 >> Dino >>=20 >> On Jul 22, 2011, at 12:48 PM, Ronald Bonica wrote: >>=20 >>> Folks, >>>=20 >>> In Section 4.1 of the draft-ietf-lisp you say: >>>=20 >>> In order to defer the need for a mapping lookup in the reverse >>> direction, an ETR MAY create a cache entry that maps the source EID >>> (inner header source IP address) to the source RLOC (outer header >>> source IP address) in a received LISP packet. Such a cache entry >> is >>> termed a "gleaned" mapping and only contains a single RLOC for the >>> EID in question. More complete information about additional RLOCs >>> SHOULD be verified by sending a LISP Map-Request for that EID. >> Both >>> ITR and the ETR may also influence the decision the other makes in >>> selecting an RLOC. See Section 6 for more details. >>>=20 >>> Has anyone thought through the security implications and possible >> unexpected side effects of these "gleaned" mappings? >>>=20 >>> Ron >>>=20 >>>=20 >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >=20 From dino@cisco.com Sun Jul 24 11:14:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77D21F8A64 for ; Sun, 24 Jul 2011 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiqDw-jMjCkM for ; Sun, 24 Jul 2011 11:14:34 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39D21F8A57 for ; Sun, 24 Jul 2011 11:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1991; q=dns/txt; s=iport; t=1311531274; x=1312740874; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SwOUf3qY5WEwspRKxKhl9GcObWuMHVrm5m/P8gYnx2I=; b=lBezrLQUV9ejKWZSMMcQCskdrb1+lAOpBzDOvf1k2546+5d+03l+tYS0 2adHM4/xYukTSTCh6pPmlqW5ojK9jJJBa88U0ZTHzzRGpZdg5Eew7BK+c 6UX9QyzMlsyGWhFQi3Sf3Gk3ArEiHX1H19V/HiDLZjC5gx02U7HGBEyQO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGFgLE6rRDoI/2dsb2JhbAA1AQEBAQIBFAFjCgMFDAwOBAY6FD4TBxcgB6csd4h8BJ9vnSqFYF8Eh1WLG4UHi3k X-IronPort-AV: E=Sophos;i="4.67,257,1309737600"; d="scan'208";a="5925545" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-6.cisco.com with ESMTP; 24 Jul 2011 18:14:34 +0000 Received: from [10.21.118.158] ([10.21.118.158]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6OIEXQn015301; Sun, 24 Jul 2011 18:14:33 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Sun, 24 Jul 2011 11:14:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> To: Patrick Frejborg X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 18:14:35 -0000 How about a simpler solution where an ITR at a site does not accept any = UDP 4341 packets? So when a host that wants to spoof a source-EID with a = valid RLOC in the outer header (so the uRPF check succeeds), can be = caught by an non-compromised ITR.=20 Routers today can do this by uRPFing solely on the EIDs and since the = RLOC belongs to the ITR itself, anyone at the site originated a packet = with that RLOC will uRPF fail. Dino On Jul 24, 2011, at 1:32 AM, Patrick Frejborg wrote: > On Fri, Jul 22, 2011 at 7:04 PM, Dino Farinacci = wrote: >> Also, we do have data-plane gleaning in an ETR specified in the spec. = So the >> packet could be accepted in an ETR, source-EID and RLOC gleaned, and = when >> the SYN-ACK is returned, the map-cache can be verified. That way, you = put >> the mapping database lookup in the place where it is already being = done for >> other reasons. >>=20 >> This is a tough problem. We will probably discuss this next week. = Luigi has >> an agenda slot to discuss LISP related security threats. >>=20 >=20 > Dino, > I don't know if this is an appropriate moment to step forward and say > that this issue can be mitigated if you give up one of the LISP > principles, i.e. no changes to endpoint stacks. If LISP also supports > upgraded stacks then the enterprise have a choice - live with the risk > of a potential DoS attack or mitigate it for the most important > services by upgrading the stack at some endpoints. Of course, both > endpoints of a session needs to be upgraded to mitigate the attack. > By going after the stack we also gain a bunch of new incentives that > enterprises should be interested in. > Have a look at RFC 6306 but the new architecture that I'm thinking of > is best described in > http://www.cs.princeton.edu/research/techreps/TR-885-10 > LISP is the first important step towards this kind of architecture - > thus I don't want to lose it. >=20 > Patrick From dino@cisco.com Sun Jul 24 11:22:41 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C777821F8A7E for ; Sun, 24 Jul 2011 11:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-1.995, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaAKDp-wSPuF for ; Sun, 24 Jul 2011 11:22:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB421F8A7D for ; Sun, 24 Jul 2011 11:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2330; q=dns/txt; s=iport; t=1311531755; x=1312741355; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/9/RO89W7PpUM/Tw7NKLsIdOs+n2XoY1/ZPeLFlr7GM=; b=IaJmeku3nUGgeFNRr3ogerhBW7WzGkSnBh4Ek1Kjyyfdfv+3on0q3cye ecyYmLqBPc9NmyxUaDr4PMiWFZ/cfgr8nTckcXNT6TY60O26/WeHr9RAZ gP8K2sLrLAx7ZOlVhrvAGcYrvRtlCfUUVh8nWxHbhILJZYU5yOkezM6yW w=; X-IronPort-AV: E=Sophos;i="4.67,257,1309737600"; d="scan'208";a="5926690" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jul 2011 18:22:34 +0000 Received: from [10.21.118.158] ([10.21.118.158]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6OILD8P013466; Sun, 24 Jul 2011 18:22:34 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> Date: Sun, 24 Jul 2011 11:22:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2FD330-6463-433B-B24A-91EADB00236B@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 18:22:41 -0000 If people agree with this, we could add text to reflect this extra = check. Dino On Jul 24, 2011, at 11:14 AM, Dino Farinacci wrote: > How about a simpler solution where an ITR at a site does not accept = any UDP 4341 packets? So when a host that wants to spoof a source-EID = with a valid RLOC in the outer header (so the uRPF check succeeds), can = be caught by an non-compromised ITR.=20 >=20 > Routers today can do this by uRPFing solely on the EIDs and since the = RLOC belongs to the ITR itself, anyone at the site originated a packet = with that RLOC will uRPF fail. >=20 > Dino >=20 > On Jul 24, 2011, at 1:32 AM, Patrick Frejborg wrote: >=20 >> On Fri, Jul 22, 2011 at 7:04 PM, Dino Farinacci = wrote: >>> Also, we do have data-plane gleaning in an ETR specified in the = spec. So the >>> packet could be accepted in an ETR, source-EID and RLOC gleaned, and = when >>> the SYN-ACK is returned, the map-cache can be verified. That way, = you put >>> the mapping database lookup in the place where it is already being = done for >>> other reasons. >>>=20 >>> This is a tough problem. We will probably discuss this next week. = Luigi has >>> an agenda slot to discuss LISP related security threats. >>>=20 >>=20 >> Dino, >> I don't know if this is an appropriate moment to step forward and say >> that this issue can be mitigated if you give up one of the LISP >> principles, i.e. no changes to endpoint stacks. If LISP also supports >> upgraded stacks then the enterprise have a choice - live with the = risk >> of a potential DoS attack or mitigate it for the most important >> services by upgrading the stack at some endpoints. Of course, both >> endpoints of a session needs to be upgraded to mitigate the attack. >> By going after the stack we also gain a bunch of new incentives that >> enterprises should be interested in. >> Have a look at RFC 6306 but the new architecture that I'm thinking of >> is best described in >> http://www.cs.princeton.edu/research/techreps/TR-885-10 >> LISP is the first important step towards this kind of architecture - >> thus I don't want to lose it. >>=20 >> Patrick >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Sun Jul 24 12:20:31 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DAD21F893E for ; Sun, 24 Jul 2011 12:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0JQERNSC-XA for ; Sun, 24 Jul 2011 12:20:31 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id D301D21F8586 for ; Sun, 24 Jul 2011 12:20:30 -0700 (PDT) Received: from dhcp-922c.meeting.ietf.org (unknown [130.129.10.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 271691C54A1; Sun, 24 Jul 2011 21:20:26 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 271691C54A1 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311535226; bh=M1pTR4uTOI2DCv7gNuPGPve6FVx2ULuMKJ8MUe2yR1Q=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=zeon0F+KZnQ2YZ59x4nTuRrOwnPx8R+GlcCxHpwhloRpFEwA6f4fd2MZ4hU5DXrEy yoLJrwwz8ylSZ9OmOFxRNFXJ3dSRsoPDHBJLPWNDCNDMOzI2rPRiGHJL6vWonrEXWT ihgKVVPYkwP++8PDbhqioi8gPuBzQABtTo/Rmo6o= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431CCE6@EMBX01-WF.jnpr.net> Date: Sun, 24 Jul 2011 11:31:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78CC905A-02FB-41E4-B802-9CBF2D855455@uclouvain.be> References: <20110722235550.00F5718C102@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F431CCE6@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 271691C54A1.A24D7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: Noel Chiappa , "lisp@ietf.org" Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 19:20:31 -0000 Ron, Noel, On 23 Jul 2011, at 16:10, Ronald Bonica wrote: > Hi Noel, >=20 > If you would like, I would be glad to write something about the DoS = issues. I suspect that this should go in the Security Considerations = Section. >=20 I am not sure that focusing on DoS is the best way to discuss the problem as it may also appear with legitimate traffic. Maybe the section could propose two example, a (D)DoS one and a=20 flash crowd one. In addition to the cache size, the update rate should also be discussed. We should look at what speed the cache can be update. Last time I tried the router did accept only a few thousands of updates per second. But I didn't tried to forward traffic at the same time, only generating misses. Cheers, Damien Saucez > Ron >=20 >=20 >> -----Original Message----- >> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] >> Sent: Friday, July 22, 2011 7:56 PM >> To: lisp@ietf.org >> Cc: jnc@mercury.lcs.mit.edu >> Subject: RE: [lisp] Fwd: Anybody can participate in the IETF (Was: = Why >> is IPv6 broken?) >>=20 >>> From: Ronald Bonica >>=20 >>> The following is the text that I promised. >>=20 >> This sounds more like text that would address something we discussed >> several >> months ago (about how to size the cache)? I was expecting something >> that would >> focus a little more on DoS issues? >>=20 >> Other than that, this text looks good. (Although "shown" feels better >> on my >> ear than "proven"... :-) Did you want to add references to the two >> papers >> that study/model cache performance issues? >>=20 >> Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Sun Jul 24 12:40:47 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7189A21F871E for ; Sun, 24 Jul 2011 12:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK1q720htqps for ; Sun, 24 Jul 2011 12:40:46 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA221F86EC for ; Sun, 24 Jul 2011 12:40:46 -0700 (PDT) Received: from dhcp-922c.meeting.ietf.org (unknown [130.129.10.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ECDE31C54A3; Sun, 24 Jul 2011 21:40:41 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be ECDE31C54A3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311536442; bh=Yc+/pI2WpRhW9U62H8ZwVpntyOSXUlcC7kDeJQrsnAg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qlL0mlaS0GuTROXmo/ldkdkAxlAwQUGxj32s7X/33+RyqFuDxnLHrEKOYE4/aPIyf nm1XzWN/MzDbeFfgPkauf+7E4aVlTbqa+UVtz7H6IiQTfE11pyupqzy+JXbORGJYEN VLOGT5qKmbDJSjBh6kmUFUfmHWrRdBofp17hekLc= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> Date: Sun, 24 Jul 2011 15:40:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CE1971C-0AF3-4C29-B9AB-96E96D3D3049@uclouvain.be> References: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ECDE31C54A3.A319D X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 19:40:47 -0000 Hello, On 22 Jul 2011, at 15:48, Ronald Bonica wrote: > Folks, >=20 > In Section 4.1 of the draft-ietf-lisp you say: >=20 > In order to defer the need for a mapping lookup in the reverse > direction, an ETR MAY create a cache entry that maps the source EID > (inner header source IP address) to the source RLOC (outer header > source IP address) in a received LISP packet. Such a cache entry is > termed a "gleaned" mapping and only contains a single RLOC for the > EID in question. More complete information about additional RLOCs > SHOULD be verified by sending a LISP Map-Request for that EID. Both > ITR and the ETR may also influence the decision the other makes in > selecting an RLOC. See Section 6 for more details. >=20 > Has anyone thought through the security implications and possible = unexpected side effects of these "gleaned" mappings? >=20 Gleaning can be used to leverage many attacks (see = draft-ietf-lisp-threats). In this doc, we also provide a section related only to security issues with gleaning (Sec 7.3) Damien Saucez > Ron >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rbonica@juniper.net Sun Jul 24 15:55:01 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFF421F8784 for ; Sun, 24 Jul 2011 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shlLV4+Lrx6O for ; Sun, 24 Jul 2011 15:55:01 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A11B021F8743 for ; Sun, 24 Jul 2011 15:54:52 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTiyivN8vJYDmNVGBowgPI/oQ14bCXrr0@postini.com; Sun, 24 Jul 2011 15:55:01 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 24 Jul 2011 15:51:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sun, 24 Jul 2011 18:51:25 -0400 From: Ronald Bonica To: Damien Saucez Date: Sun, 24 Jul 2011 18:51:23 -0400 Thread-Topic: [lisp] gleaned mappings Thread-Index: AcxKOZZ4NzeVXSRmSmWakb/MlKs1FwAGnIDQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431CDB4@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431C975@EMBX01-WF.jnpr.net> <7CE1971C-0AF3-4C29-B9AB-96E96D3D3049@uclouvain.be> In-Reply-To: <7CE1971C-0AF3-4C29-B9AB-96E96D3D3049@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] gleaned mappings X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 22:55:02 -0000 Damien, That's a very reasonable answer. Maybe Section 4.1 of the draft-ietf-lisp s= hould include a reference to Section 7.3 of draft-ietf-list-threats? Ron > -----Original Message----- > From: Damien Saucez [mailto:damien.saucez@uclouvain.be] > Sent: Sunday, July 24, 2011 3:41 PM > To: Ronald Bonica > Cc: lisp@ietf.org > Subject: Re: [lisp] gleaned mappings >=20 > Hello, > On 22 Jul 2011, at 15:48, Ronald Bonica wrote: >=20 > > Folks, > > > > In Section 4.1 of the draft-ietf-lisp you say: > > > > In order to defer the need for a mapping lookup in the reverse > > direction, an ETR MAY create a cache entry that maps the source EID > > (inner header source IP address) to the source RLOC (outer header > > source IP address) in a received LISP packet. Such a cache entry > is > > termed a "gleaned" mapping and only contains a single RLOC for the > > EID in question. More complete information about additional RLOCs > > SHOULD be verified by sending a LISP Map-Request for that EID. > Both > > ITR and the ETR may also influence the decision the other makes in > > selecting an RLOC. See Section 6 for more details. > > > > Has anyone thought through the security implications and possible > unexpected side effects of these "gleaned" mappings? > > >=20 > Gleaning can be used to leverage many attacks (see draft-ietf-lisp- > threats). In > this doc, we also provide a section related only to security issues > with > gleaning (Sec 7.3) >=20 > Damien Saucez >=20 > > Ron > > > > > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp From jsw@inconcepts.biz Sun Jul 24 18:35:05 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2AB21F84BC for ; Sun, 24 Jul 2011 18:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpck+zAqk5k9 for ; Sun, 24 Jul 2011 18:35:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9764F21F84B7 for ; Sun, 24 Jul 2011 18:35:04 -0700 (PDT) Received: by vws12 with SMTP id 12so3349082vws.31 for ; Sun, 24 Jul 2011 18:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.161 with SMTP id dh1mr3855105vdc.177.1311557704044; Sun, 24 Jul 2011 18:35:04 -0700 (PDT) Received: by 10.220.194.133 with HTTP; Sun, 24 Jul 2011 18:35:04 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> Date: Sun, 24 Jul 2011 21:35:04 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a8e560d520204a8dad37f Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 01:35:05 -0000 --bcaec51a8e560d520204a8dad37f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci wrote: > How about a simpler solution where an ITR at a site does not accept any UDP > 4341 packets? So when a host that wants to spoof a source-EID with a valid > RLOC in the outer header (so the uRPF check succeeds), can be caught by an > non-compromised ITR. > > Routers today can do this by uRPFing solely on the EIDs and since the RLOC > belongs to the ITR itself, anyone at the site originated a packet with that > RLOC will uRPF fail. > I do not understand how this is helpful. Perhaps you could give an example of how this would work if the Internet were in a transition state, with both many LISP sites, and many "legacy" sites? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --bcaec51a8e560d520204a8dad37f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci = <dino@cisco.com&= gt; wrote:
How about a simpler solution where an ITR at a site does not accept any UDP= 4341 packets? So when a host that wants to spoof a source-EID with a valid= RLOC in the outer header (so the uRPF check succeeds), can be caught by an= non-compromised ITR.

Routers today can do this by uRPFing solely on the EIDs and since the RLOC = belongs to the ITR itself, anyone at the site originated a packet with that= RLOC will uRPF fail.

I do not understand how this = is helpful. =A0Perhaps you could give an example of how this would work if = the Internet were in a transition state, with both many LISP sites, and man= y "legacy" sites?

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator=A0 /=A0 Innov= ative Network Concepts
--bcaec51a8e560d520204a8dad37f-- From pfrejborg@gmail.com Mon Jul 25 00:39:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8E21F8B00 for ; Mon, 25 Jul 2011 00:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIA6WZRzBocc for ; Mon, 25 Jul 2011 00:39:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A321F850E for ; Mon, 25 Jul 2011 00:39:14 -0700 (PDT) Received: by ewy19 with SMTP id 19so2613325ewy.31 for ; Mon, 25 Jul 2011 00:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VmTnUvVk2yt9vINBfhwzQQNJkW30EQV4FRheLcWznMM=; b=unuFqDPV7CIyK/fjd7Unr7FzaHN5Kw840l1tQNxBc7Q1IxpB6rfQ1jCAWMyXCfv3cc Est5xGbyYgh8DPAFp/NExgQ0Xi80WX2f5wJG6SaZTvv/pgp+hkmIGUyyoYSLXGiHcinS qwpJ0MaBT/LLY3puW8l3gpikPdPpMHSfJ3UPk= MIME-Version: 1.0 Received: by 10.213.27.18 with SMTP id g18mr1539657ebc.50.1311579553427; Mon, 25 Jul 2011 00:39:13 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Mon, 25 Jul 2011 00:39:13 -0700 (PDT) In-Reply-To: References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> Date: Mon, 25 Jul 2011 10:39:13 +0300 Message-ID: From: Patrick Frejborg To: Jeff Wheeler , Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:39:15 -0000 On Mon, Jul 25, 2011 at 4:35 AM, Jeff Wheeler wrote: > On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci wrote: >> >> How about a simpler solution where an ITR at a site does not accept any >> UDP 4341 packets? So when a host that wants to spoof a source-EID with a >> valid RLOC in the outer header (so the uRPF check succeeds), can be caug= ht >> by an non-compromised ITR. >> >> Routers today can do this by uRPFing solely on the EIDs and since the RL= OC >> belongs to the ITR itself, anyone at the site originated a packet with t= hat >> RLOC will uRPF fail. > > I do not understand how this is helpful. =A0Perhaps you could give an exa= mple > of how this would work if the Internet were in a transition state, with b= oth > many LISP sites, and many "legacy" sites? Me either. The only way (except from going after the stack) I see to get around this is to have the following: - have ETR and ITR in the same box (xTR). - ETR is not doing uRPF but it inspect the incoming SYN-packets and pre-select mappings for the ITR so that ITR is "warned" when ACK-packtes are returned from the server - the mapping database has to be installed locally at the xTR, because the time of the reply from the mapping system must be shorter than it takes for the SYN packet to become an ACK packet. If not, then the xTR needs to store the packet in memory (which is expensive at higher speeds) or drop it but we have to assume that valid traffic have already been dropped or delayed at the ingress ITR. So doing that a second time is not helpful. Also the mapping system must always respond promptly to an ITR, if there are several ITRs using the same server how to ensure that an ITR under attack gets priority so that the mapping requests are further delayed (apart from the light of speed issue). - make sure that the punting resources are higher than the bandwidth capacity at the xTR. Then if LISP gets widely deployed there is the botnet issue with clients at dispersed EID prefixes, these will not be caught by a uRPF filter but they could generate a lot of cache entries depending on how many +/- mappings each EID prefix provides. Patrick From dino@cisco.com Mon Jul 25 06:12:30 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AC221F889D for ; Mon, 25 Jul 2011 06:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+FyVxHAc7DU for ; Mon, 25 Jul 2011 06:12:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8AE21F887C for ; Mon, 25 Jul 2011 06:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=4425; q=dns/txt; s=iport; t=1311599549; x=1312809149; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=A7gNJ18WdG55IKgjuy0fPEewqmmun8w9EtJsXfmD4r0=; b=c6OCt9+l1cYuevNsysYl9/g3KAN/RXm97JqV4IJAFvJnVQTQTMcR7sUZ AJt23mpH3e6YPUIELDvAt3bpAPb6snjm3x7NFtsBwUy6Vv3B/jmW27TGc QPNSYdVI/o4Vp7g00U4UsnZ9gPIm6qwGS4y45bF54m9vek6L2jZODErCM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFxrLU6rRDoJ/2dsb2JhbAA0AQEBAQIBFAFwBQwMDgo6FFEHFyAHpzB3iHyiN51whWBfBIdVixuRAA X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6104770" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2011 13:12:28 +0000 Received: from sjc-vpn7-122.cisco.com (sjc-vpn7-122.cisco.com [10.21.144.122]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDCQmT002803; Mon, 25 Jul 2011 13:12:27 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 06:12:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> To: Patrick Frejborg X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:12:30 -0000 > On Mon, Jul 25, 2011 at 4:35 AM, Jeff Wheeler = wrote: >> On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci = wrote: >>>=20 >>> How about a simpler solution where an ITR at a site does not accept = any >>> UDP 4341 packets? So when a host that wants to spoof a source-EID = with a >>> valid RLOC in the outer header (so the uRPF check succeeds), can be = caught >>> by an non-compromised ITR. >>>=20 >>> Routers today can do this by uRPFing solely on the EIDs and since = the RLOC >>> belongs to the ITR itself, anyone at the site originated a packet = with that >>> RLOC will uRPF fail. >>=20 >> I do not understand how this is helpful. Perhaps you could give an = example >> of how this would work if the Internet were in a transition state, = with both >> many LISP sites, and many "legacy" sites? >=20 > Me either. I was focusing one case at the moment. That was the one that Jeff = brought up. It was a compromised host in a LISP site with = non-compromised ITRs. This case can be solved. For your reference to "transition state", there isn't this same issue on = a PITR because it receives and forwards packets from non-LISP sites, = where there is one IP header in the packet, and the source address is = subject to uRPF and forwarding rules as it is today. > The only way (except from going after the stack) I see to get around > this is to have the following: > - have ETR and ITR in the same box (xTR). For which case, can you be specific please? > - ETR is not doing uRPF but it inspect the incoming SYN-packets and > pre-select mappings for the ITR so that ITR is "warned" when > ACK-packtes are returned from the server Let's be careful how you use the term uRPF in context to LISP. Let's = keep the definition as the current definition. Let's refer to an ETR = doing a mapping database lookup to verify the source locator and the = source EID are in sync to be "binding verification". The ETR can do binding verification when it decapsulates packets. It = doesn't matter what type of packet it is and it doesn't have to be an = ITR to do this and it doesn't have to correlate with any other cross = packet state. I am not suggesting this is the best way. We are just discussing = options. > - the mapping database has to be installed locally at the xTR, because > the time of the reply from the mapping system must be shorter than it > takes for the SYN packet to become an ACK packet. If not, then the xTR > needs to store the packet in memory (which is expensive at higher > speeds) or drop it but we have to assume that valid traffic have > already been dropped or delayed at the ingress ITR. So doing that a Right, so you have some hard decisions to make. The ETR can do lookup in = its cache to figure out if the (source-RLOC, source-EID) is in its cache = and if not, drop the packet, then do a lookup so subsequent packets can = have the cache populated so the check can pass. I would prefer to not propose this solution. I'd rather try to solve on = the ITR and make the solution closer to the source. > second time is not helpful. Also the mapping system must always > respond promptly to an ITR, if there are several ITRs using the same > server how to ensure that an ITR under attack gets priority so that > the mapping requests are further delayed (apart from the light of > speed issue). Agree, but these issues are no different than what we see in the DNS = today. It is too hard and won't scale to differentiate and if anyone = tries to figure a solution to this bit, it probably can't work. I call this the "needle in the haystack" problem. And we have had to = deal with this with hardware packet punting for a number of decades. > - make sure that the punting resources are higher than the bandwidth > capacity at the xTR. Yep. > Then if LISP gets widely deployed there is the botnet issue with > clients at dispersed EID prefixes, these will not be caught by a uRPF > filter but they could generate a lot of cache entries depending on how > many +/- mappings each EID prefix provides. That is why you solve it at the encapsulator end of this so you don't = have to query the mapping database *for your own EID-prefixes*. The ITR = has all the information it needs locally to determine to pass a packet = from a source or not. Dino From jsw@inconcepts.biz Mon Jul 25 10:41:10 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29E21F8BDC for ; Mon, 25 Jul 2011 10:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kvf0ACfi3WkU for ; Mon, 25 Jul 2011 10:41:10 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF821F8BB6 for ; Mon, 25 Jul 2011 10:41:09 -0700 (PDT) Received: by vws12 with SMTP id 12so3930351vws.31 for ; Mon, 25 Jul 2011 10:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.158.197 with SMTP id g5mr1200391vcx.254.1311615669168; Mon, 25 Jul 2011 10:41:09 -0700 (PDT) Received: by 10.220.194.70 with HTTP; Mon, 25 Jul 2011 10:41:09 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> Date: Mon, 25 Jul 2011 13:41:09 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:41:10 -0000 On Mon, Jul 25, 2011 at 9:12 AM, Dino Farinacci wrote: > For your reference to "transition state", there isn't this same issue on = a PITR because it receives and forwards packets from non-LISP sites, where = there is one IP header in the packet, and the source address is subject to = uRPF and forwarding rules as it is today. The reason I mention "transition state" is you seem to be gravitating towards ideas that require new inspection capabilities at substantially all "legacy Internet" access providers in order to protect the new LISP infrastructure. If I can use any source IP address I want when sending crafted packets, including crafted LISP outer-header, to your LISP site, then the chances are good that I can disable your site as long as I can generate enough PPS and there are enough mappings in the system to produce cache churn in your xTR. So relying on ITRs to prevent "bad traffic" from ever entering the system will not work because there will be a large, legacy Internet with no ability to prevent that traffic from reaching your site. > Right, so you have some hard decisions to make. The ETR can do lookup in = its cache to figure out if the (source-RLOC, source-EID) is in its cache an= d if not, drop the packet, then do a lookup so subsequent packets can have = the cache populated so the check can pass. Except the ETR is bounded by the same cache scaling limits as an ITR subject to a reflection attack, meaning its cache can churn, and substantially all traffic needing to be decapsulated by that ETR would be dropped. > I call this the "needle in the haystack" problem. And we have had to deal= with this with hardware packet punting for a number of decades. Even if you imagine that the xTR control-plane is not a bottleneck, presuming that the data-plane can generate MS queries directly and can update its FIB at an unlimited rate, the result of having a limited FIB size plus an attack designed to take advantage of that means the MS infrastructure will be required to have very low latency and very high throughput to keep up with an xTR experiencing high PPS and low cache hit rate because of churn. This essentially would mean that the MS infrastructure is directly involved in a substantial fraction of packet forwarding decisions on that xTR. -- Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From dino@cisco.com Mon Jul 25 11:03:32 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB021F8BF8 for ; Mon, 25 Jul 2011 11:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.613 X-Spam-Level: X-Spam-Status: No, score=-3.613 tagged_above=-999 required=5 tests=[AWL=-1.813, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umt8YV8YfHqV for ; Mon, 25 Jul 2011 11:03:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 80E4B21F8BCD for ; Mon, 25 Jul 2011 11:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2944; q=dns/txt; s=iport; t=1311617011; x=1312826611; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=r9AEuYN0r9zfinAdalXyzsevQW+XGk1UvLCCqQyOtBg=; b=gLBQ9Scb0dyeHxnwjqY8lp8/x04jxpXNodgtfoGZhzcrmypNwyzCDJ8k U8yORl/PndURXuwJxsScQhNfcfT2W5/6yeVs6t6c/Yhp8ta/iZE5swFZM WRQ0/iWimyKnABFWbEYq/3RZsLLLthg7VZn1AYCQTSdz6v7lP6W5YC1/l s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFuvLU6rRDoI/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDA4KOhQYOQcXIAenMneIfASheJ4chWBfBIdVixuRAA X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="scan'208";a="6207792" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2011 18:03:31 +0000 Received: from sjc-vpn4-714.cisco.com (sjc-vpn4-714.cisco.com [10.21.82.202]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6PI3U1u031014; Mon, 25 Jul 2011 18:03:30 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 11:03:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:03:32 -0000 > On Mon, Jul 25, 2011 at 9:12 AM, Dino Farinacci = wrote: >> For your reference to "transition state", there isn't this same issue = on a PITR because it receives and forwards packets from non-LISP sites, = where there is one IP header in the packet, and the source address is = subject to uRPF and forwarding rules as it is today. >=20 > The reason I mention "transition state" is you seem to be gravitating > towards ideas that require new inspection capabilities at > substantially all "legacy Internet" access providers in order to > protect the new LISP infrastructure. If I can use any source IP > address I want when sending crafted packets, including crafted LISP > outer-header, to your LISP site, then the chances are good that I can > disable your site as long as I can generate enough PPS and there are > enough mappings in the system to produce cache churn in your xTR. >=20 > So relying on ITRs to prevent "bad traffic" from ever entering the > system will not work because there will be a large, legacy Internet > with no ability to prevent that traffic from reaching your site. How many times do I have to say we should not solve this on the ETR? >> Right, so you have some hard decisions to make. The ETR can do lookup = in its cache to figure out if the (source-RLOC, source-EID) is in its = cache and if not, drop the packet, then do a lookup so subsequent = packets can have the cache populated so the check can pass. >=20 > Except the ETR is bounded by the same cache scaling limits as an ITR > subject to a reflection attack, meaning its cache can churn, and > substantially all traffic needing to be decapsulated by that ETR would > be dropped. Right, agree. Don't do this on the ETR. DO NOT SOLVE THIS ON THE ETR. >> I call this the "needle in the haystack" problem. And we have had to = deal with this with hardware packet punting for a number of decades. >=20 > Even if you imagine that the xTR control-plane is not a bottleneck, > presuming that the data-plane can generate MS queries directly and can Why do you want to presume that? > update its FIB at an unlimited rate, the result of having a limited > FIB size plus an attack designed to take advantage of that means the > MS infrastructure will be required to have very low latency and very > high throughput to keep up with an xTR experiencing high PPS and low > cache hit rate because of churn. This essentially would mean that the > MS infrastructure is directly involved in a substantial fraction of > packet forwarding decisions on that xTR. That doesn't follow at all and I don't know why you want to make this = conclusion. Dino >=20 > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jsw@inconcepts.biz Mon Jul 25 12:20:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39BE11E808F for ; Mon, 25 Jul 2011 12:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bUzzZujDCkB for ; Mon, 25 Jul 2011 12:20:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6117A21F884C for ; Mon, 25 Jul 2011 12:20:47 -0700 (PDT) Received: by vxi40 with SMTP id 40so4005995vxi.31 for ; Mon, 25 Jul 2011 12:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.138 with SMTP id w10mr4843833vdt.43.1311621646761; Mon, 25 Jul 2011 12:20:46 -0700 (PDT) Received: by 10.220.194.70 with HTTP; Mon, 25 Jul 2011 12:20:46 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> Date: Mon, 25 Jul 2011 15:20:46 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:20:48 -0000 On Mon, Jul 25, 2011 at 2:03 PM, Dino Farinacci wrote: >> Even if you imagine that the xTR control-plane is not a bottleneck, >> presuming that the data-plane can generate MS queries directly and can > > Why do you want to presume that? To demonstrate that this is not simply a control-plane bottleneck. >> update its FIB at an unlimited rate, the result of having a limited >> FIB size plus an attack designed to take advantage of that means the >> MS infrastructure will be required to have very low latency and very >> high throughput to keep up with an xTR experiencing high PPS and low >> cache hit rate because of churn. =A0This essentially would mean that the >> MS infrastructure is directly involved in a substantial fraction of >> packet forwarding decisions on that xTR. > > That doesn't follow at all and I don't know why you want to make this con= clusion. It is correct. If the xTR does not have the necessary state to forward a packet, it must communicate with the MS infrastructure. As cache hit rate goes down, direct MS involvement in forwarding operations goes up. The MS does not see the packet itself, but it must perform work for each miss. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From dino@cisco.com Mon Jul 25 12:26:14 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F742228011 for ; Mon, 25 Jul 2011 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgnS2dz2klae for ; Mon, 25 Jul 2011 12:26:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 84A0C22800F for ; Mon, 25 Jul 2011 12:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=456; q=dns/txt; s=iport; t=1311621973; x=1312831573; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vGAYL1EiI2QPGxlXbP8NeAmWe7fPQlh5bDmUoYb1b+w=; b=hKY9R8ht1Ea9HE2PNdZsRK2HehH8Y6jS58iqlQrMMbYdqNxb9VwXju6j tj0dl8xnm7PEFCZYcGKB632bD2bcjPNEyhqQ85rL7xj3hXt5LOIKkt/DI CSqwYM0TPMbFfOPT9Gbkd3sAH8lIF8tHGr8/LadIbamjzuwvgH5D2kY8e k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB/CLU6tJXG//2dsb2JhbAA0AQEBAQIBFAFwBQwMDkQUUQc3B6czd4h8oWSeKYVgXwSHVYsbkQA X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6231632" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2011 19:26:13 +0000 Received: from sjc-vpn7-1008.cisco.com (sjc-vpn7-1008.cisco.com [10.21.147.240]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PJQCrL019030; Mon, 25 Jul 2011 19:26:12 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 12:26:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:26:14 -0000 > It is correct. If the xTR does not have the necessary state to > forward a packet, it must communicate with the MS infrastructure. As > cache hit rate goes down, direct MS involvement in forwarding > operations goes up. The MS does not see the packet itself, but it > must perform work for each miss. Darrel has already mentioned that the ITR can "forward-on-cache-miss" by = default if the implementation wants to protect its cache. Dino From jsw@inconcepts.biz Mon Jul 25 12:39:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694F121F8AC9 for ; Mon, 25 Jul 2011 12:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZFF-I8bjztP for ; Mon, 25 Jul 2011 12:39:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66FCA21F884F for ; Mon, 25 Jul 2011 12:39:47 -0700 (PDT) Received: by vws12 with SMTP id 12so4023351vws.31 for ; Mon, 25 Jul 2011 12:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.47 with SMTP id r15mr4650532vdf.110.1311622786844; Mon, 25 Jul 2011 12:39:46 -0700 (PDT) Received: by 10.220.194.70 with HTTP; Mon, 25 Jul 2011 12:39:46 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> Date: Mon, 25 Jul 2011 15:39:46 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:39:48 -0000 On Mon, Jul 25, 2011 at 3:26 PM, Dino Farinacci wrote: > Darrel has already mentioned that the ITR can "forward-on-cache-miss" by = default if the implementation wants to protect its cache. How can these packets arrive at their destination? --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From damien.saucez@uclouvain.be Mon Jul 25 12:40:54 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1A21F8B10 for ; Mon, 25 Jul 2011 12:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAUGQQf24dRH for ; Mon, 25 Jul 2011 12:40:54 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8D21F8B09 for ; Mon, 25 Jul 2011 12:40:53 -0700 (PDT) Received: from [IPv6:2001:df8::8:226:bbff:fe0e:882c] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4D9C611E2E0; Mon, 25 Jul 2011 21:40:49 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 4D9C611E2E0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311622849; bh=B1SjU4SeHuRv5WUysFMuP3hxOW+9wLrawnn+K75ttK0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lRwaEnASJ3H3BRmH2S3j7hwf9j34PL2o1iCbhcx57RtFRHQxr42c6Yj6OfhtIg5gF UGnICPptdScrK8VsYj0iMByOrcPh7V+skVPCmRjKItzgXNz9hf/Rn3361HIaRy4CLG mN9hTNNhBCtP8GA4uXL/QFGp6ixe9oMskoyY+3Ms= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: Date: Mon, 25 Jul 2011 15:40:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <182AC78B-57D7-4ACD-ACFF-EAF6B05FB8BB@uclouvain.be> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 4D9C611E2E0.A1F70 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:40:54 -0000 On 25 Jul 2011, at 15:39, Jeff Wheeler wrote: > On Mon, Jul 25, 2011 at 3:26 PM, Dino Farinacci = wrote: >> Darrel has already mentioned that the ITR can "forward-on-cache-miss" = by default if the implementation wants to protect its cache. >=20 > How can these packets arrive at their destination? >=20 PITR > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jnc@mercury.lcs.mit.edu Mon Jul 25 12:42:15 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE35521F8B10 for ; Mon, 25 Jul 2011 12:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msWmi6I0uIzv for ; Mon, 25 Jul 2011 12:42:15 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7321F8B09 for ; Mon, 25 Jul 2011 12:42:15 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BFAC518C0CD; Mon, 25 Jul 2011 15:42:13 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110725194213.BFAC518C0CD@mercury.lcs.mit.edu> Date: Mon, 25 Jul 2011 15:42:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:42:16 -0000 > From: Jeff Wheeler > If the xTR does not have the necessary state to forward a packet, it must > communicate with the MS infrastructure. As cache hit rate goes down, > direct MS involvement in forwarding operations goes up. To a certain point, yes... but we do _already_ have rate-limits on the ITR->resolution_system, precisely to protect the resolution system. I mean, imagine a scenario where an ITR gets taken over by a bad guy - or, simpler yet, a bad guy claims to be an ITR when they are not. The attacker could then generate as much traffic to the resolution system as they want; they are a direct threat to the resolution system, i.e. not via churning the cache on an ITR. The best cache management in the world cannot prevent such direct DoS attacks on the mapping infrastructure. So such threats exist irrespective of DoS attacks on caches, i.e. have to be protected against directly All sorts of DoS attacks are possible. Imagine a system in which all ITRs have all mappings (e.g. through NERD, or something like that). So a DoS attack there would consist of having a number of sites update their mappings at high rates. (That would be an even better attack, since it's a multiplier attack - i.e. each attack packet would produce an expanding cascade of pacekts, at the syetem attemtped to update every ITR in the world with the new mapping.) Build any system, I can think of a DoS attack on it... (Are people DoS'in DNS servers yet, BTW?) To deal with DoS attacks, any system ideally i) degrades service for other clients under the load, but doesn't keel over dead, and ii) allows you to track down the source(s) of the attack and deal with them. (Preferentially by taking the perpetrators and throwing them into vats of boiling oil... but I digress.) Noel From dino@cisco.com Mon Jul 25 12:43:02 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BE011E80A9 for ; Mon, 25 Jul 2011 12:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=-1.734, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5kCoQZlYYd0 for ; Mon, 25 Jul 2011 12:43:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 49E0111E80A7 for ; Mon, 25 Jul 2011 12:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=871; q=dns/txt; s=iport; t=1311622982; x=1312832582; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/QZJuPWU0kpKsqwiBFcnmR1hj0jx34ZPJ+almnDIjlc=; b=QK6NOND9XjoAgRVTT2t8+0XNRGxOJzqJzeWaDpFka8bCIUF75e8L/FfQ hvrjHpl/KqRCR9/zqVaAUdFSWhB+Dbh5dU+cV/doQ1/8ak2RPa6dIXMs7 CqAIvO1uS9wSXSwH4JNJFBK1yRriw0M5l4vNyveLYXwIq2t+7ie7dgUlz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPXGLU6rRDoJ/2dsb2JhbAA0AQEBAQIBAQEBEQFlCwUMDA4KOhQYOQcXIAenM3eIfAShOZ4rhWBfBIdVixuRAA X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6239464" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 19:43:00 +0000 Received: from sjc-vpn7-1008.cisco.com (sjc-vpn7-1008.cisco.com [10.21.147.240]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PJh0ZL029384; Mon, 25 Jul 2011 19:43:00 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 12:42:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43E284F4-BE99-4D7B-8DAD-70E307A665D9@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 19:43:03 -0000 > On Mon, Jul 25, 2011 at 3:26 PM, Dino Farinacci = wrote: >> Darrel has already mentioned that the ITR can "forward-on-cache-miss" = by default if the implementation wants to protect its cache. >=20 > How can these packets arrive at their destination? If destined to non-LISP sites, they go natively, just like they would in = a router today. If destined for LISP sites and sent natively because you = don't want to store the locator-set for the site (due to the cache = filling up), they go natively and will hit the closest PITR which will = encapsulate to the destination LISP site. Dino >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From pfrejborg@gmail.com Mon Jul 25 13:24:24 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BDF21F8B37 for ; Mon, 25 Jul 2011 13:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAYXWAMtTQg3 for ; Mon, 25 Jul 2011 13:24:23 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16E3C21F8C32 for ; Mon, 25 Jul 2011 13:24:22 -0700 (PDT) Received: by ewy19 with SMTP id 19so3015564ewy.31 for ; Mon, 25 Jul 2011 13:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e6t2FyGz+ghkBK2GfHU0wmcaQCNlm8rGFRwh4MYedJQ=; b=GaxPmo40z/00+aQ+w3CWAWBONCjO/iRm4d0EL/7NAVvQObCQrwVf2g+0i/PK4M6CH4 2C/ZIhdljqvF49Q5kOGlHYsqEafOVqO98AAA/ayd04c+enUMcaLO3M+dIEH9SmKITUTe CRaOzSTK9mAZT6vWo4RmtuFzGTP5fb0rizPzY= MIME-Version: 1.0 Received: by 10.213.27.18 with SMTP id g18mr1796993ebc.50.1311625461812; Mon, 25 Jul 2011 13:24:21 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Mon, 25 Jul 2011 13:24:21 -0700 (PDT) In-Reply-To: <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> Date: Mon, 25 Jul 2011 23:24:21 +0300 Message-ID: From: Patrick Frejborg To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:24:24 -0000 On Mon, Jul 25, 2011 at 4:12 PM, Dino Farinacci wrote: >> The only way (except from going after the stack) I see to get around >> this is to have the following: >> - have ETR and ITR in the same box (xTR). > > For which case, can you be specific please? Hope I don't mess up the discussion but here are my inputs and think their aligned with Jeff's. First I'm discussing the case when a fake ITR (or several fake ITRs) sends bogus LISP packets to a selected ETR > >> - ETR is not doing uRPF but it inspect the incoming SYN-packets and >> pre-select mappings for the ITR so that ITR is "warned" when >> ACK-packtes are returned from the server > > Let's be careful how you use the term uRPF in context to LISP. Let's keep= the definition as the current definition. Let's refer to an ETR doing a ma= pping database lookup to verify the source locator and the source EID are i= n sync to be "binding verification". > > The ETR can do binding verification when it decapsulates packets. It does= n't matter what type of packet it is and it doesn't have to be an ITR to do= this and it doesn't have to correlate with any other cross packet state. > > I am not suggesting this is the best way. We are just discussing options. Yes, agree - the fake ITR sends bogus packets to the selected ETR and that ETR is not applying "binding verification" but instead it does a preview at the packet so that it can inform the ITR of the forthcoming returning packets from the destination EID. ITR and ETR resides in the same box, this feature suggestion is there to buy some time for ITR so it is prepared for what is going to come. I think you had some ideas in this direction but it could be a misinterpretation... > >> - the mapping database has to be installed locally at the xTR, because >> the time of the reply from the mapping system must be shorter than it >> takes for the SYN packet to become an ACK packet. If not, then the xTR >> needs to store the packet in memory (which is expensive at higher >> speeds) or drop it but we have to assume that valid traffic have >> already been dropped or delayed at the ingress ITR. So doing that a > > Right, so you have some hard decisions to make. The ETR can do lookup in = its cache to figure out if the (source-RLOC, source-EID) is in its cache an= d if not, drop the packet, then do a lookup so subsequent packets can have = the cache populated so the check can pass. > > I would prefer to not propose this solution. I'd rather try to solve on t= he ITR and make the solution closer to the source. > Me either, no cache and mapping functionality at the ETR but instead have a quick look at the incoming packets so that ITR doesn't have to fetch the information from a very slow memory (e.g. hard disk). Assumption here is that there is a local database at the ITR - but that is not the case in current I-Ds, this is an option but it has other problems... >> second time is not helpful. Also the mapping system must always >> respond promptly to an ITR, if there are several ITRs using the same >> server how to ensure that an ITR under attack gets priority so that >> the mapping requests are further delayed (apart from the light of >> speed issue). > > Agree, but these issues are no different than what we see in the DNS toda= y. It is too hard and won't scale to differentiate and if anyone tries to f= igure a solution to this bit, it probably can't work. > There is a huge difference between a DNS and a MS lookup, DNS is not in the forwarding plane at all but to build forwarding plane in LISP you need to ask the MS on how to build it - the forwarding plane is not prepared in advance. And if the MS system is fair away or can't reply to the requests at the same pace as the bogus ITR sends packets to a targeted ETR, then the ITR (that is handling the returning packets on behalf of the targeted ETR) can't establish forwarding plane in time. > I call this the "needle in the haystack" problem. And we have had to deal= with this with hardware packet punting for a number of decades. > >> - make sure that the punting resources are higher than the bandwidth >> capacity at the xTR. > > Yep. > >> Then if LISP gets widely deployed there is the botnet issue with >> clients at dispersed EID prefixes, these will not be caught by a uRPF >> filter but they could generate a lot of cache entries depending on how >> many +/- mappings each EID prefix provides. > > That is why you solve it at the encapsulator end of this so you don't hav= e to query the mapping database *for your own EID-prefixes*. The ITR has al= l the information it needs locally to determine to pass a packet from a sou= rce or not. For the first case, i.e. an attacker using a fake ITR - the attacker owning the fake ITR(s) will not do that :-) The second case is far in the future, LISP has been deployed and well established. Imagine if you have 200 000 botnet clients, each client is attached to their dedicated EID prefix and each client generates 1-10 +/- mappings per EID prefix. Now the botnet admin decides that a EID site will be attacked, he triggers a timestamped HTTP request to that EID site, a SYN goes out at the very same seconds from 200 000 botnet clients. No fake source/destination are used, all EIDs are legal and they don't get caught by uRPF. But the ITR (handling the ACKs from the attacked EID site) has to create somewhere between 200 000 to 2 millions cache entries at a pace that depends on how powerful server/servers are used to generate the 200 000 ACKs. And if there is no local database at the ITR (that is handling the ACKs) it has to consult the MS, resolve each entry and that will take some time. And if the cache size is limited, you need adjust the timers and flush the cache more often, but then the attacker can do this trick more often. After a while, when there is analyzed data, you could create a blacklist at the ITR (that is handling the returning ACKs). The numbers used here are taken from nowhere, I had to use some numbers to explain the possible scenario that could happen in the future. Patrick From jsw@inconcepts.biz Mon Jul 25 13:24:35 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70A511E80AC for ; Mon, 25 Jul 2011 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fq86v4zXLuZ for ; Mon, 25 Jul 2011 13:24:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6811E80A1 for ; Mon, 25 Jul 2011 13:24:35 -0700 (PDT) Received: by vxi40 with SMTP id 40so4056792vxi.31 for ; Mon, 25 Jul 2011 13:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.138 with SMTP id w10mr4913974vdt.43.1311625474848; Mon, 25 Jul 2011 13:24:34 -0700 (PDT) Received: by 10.220.194.70 with HTTP; Mon, 25 Jul 2011 13:24:34 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <43E284F4-BE99-4D7B-8DAD-70E307A665D9@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> <43E284F4-BE99-4D7B-8DAD-70E307A665D9@cisco.com> Date: Mon, 25 Jul 2011 16:24:34 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:24:36 -0000 On Mon, Jul 25, 2011 at 3:42 PM, Dino Farinacci wrote: > If destined to non-LISP sites, they go natively, just like they would in = a router today. If destined for LISP sites and sent natively because you do= n't want to store the locator-set for the site (due to the cache filling up= ), they go natively and will hit the closest PITR which will encapsulate to= the destination LISP site. But the PITR is subject to the same scaling limitations. The problem is unchanged. The only difference in the case of the PITR is it can be responsible for less than the entire destination address space; but an ITR could also be implemented that way. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jnc@mercury.lcs.mit.edu Mon Jul 25 13:40:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B686821F8AE9 for ; Mon, 25 Jul 2011 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.131 X-Spam-Level: X-Spam-Status: No, score=-6.131 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XemeaFvqTke for ; Mon, 25 Jul 2011 13:40:20 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3147721F8AD6 for ; Mon, 25 Jul 2011 13:40:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9DEEC18C0D9; Mon, 25 Jul 2011 16:40:19 -0400 (EDT) To: jsw@inconcepts.biz, lisp@ietf.org Message-Id: <20110725204019.9DEEC18C0D9@mercury.lcs.mit.edu> Date: Mon, 25 Jul 2011 16:40:19 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:40:20 -0000 > From: Jeff Wheeler > in the case of the PITR is it can be responsible for less than the entire > destination address space; but an ITR could also be implemented that way. I'm not so sure - a small/medium size site might have two ITRs (or a small number of them), and in those cases responsbility for covering the address space could be divided between them, but many smaller sites will only have one (their exit router). Noel From jsw@inconcepts.biz Mon Jul 25 13:56:49 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9D111E80A2 for ; Mon, 25 Jul 2011 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX7r0Sjn7FaG for ; Mon, 25 Jul 2011 13:56:48 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C300711E80AC for ; Mon, 25 Jul 2011 13:56:48 -0700 (PDT) Received: by vws12 with SMTP id 12so4082659vws.31 for ; Mon, 25 Jul 2011 13:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.38.130 with SMTP id b2mr1235093vce.184.1311627407201; Mon, 25 Jul 2011 13:56:47 -0700 (PDT) Received: by 10.220.194.70 with HTTP; Mon, 25 Jul 2011 13:56:47 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: <20110725204019.9DEEC18C0D9@mercury.lcs.mit.edu> References: <20110725204019.9DEEC18C0D9@mercury.lcs.mit.edu> Date: Mon, 25 Jul 2011 16:56:47 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 20:56:49 -0000 On Mon, Jul 25, 2011 at 4:40 PM, Noel Chiappa wro= te: > I'm not so sure - a small/medium size site might have two ITRs (or a smal= l > number of them), and in those cases responsbility for covering the addres= s > space could be divided between them, but many smaller sites will only hav= e one > (their exit router). I agree. However, if the solution for ITR cache churn is to "Hail Mary" the packets up to the native Internet (assuming native connectivity for that Address Family is even available) then these packets must find their way to an xTR that can handle the traffic, or they will be dropped. This must be the very powerful router (or cluster) that some have mentioned -- but you have to be able to build and sell it at practical size, power/heat properties, and price. So saying this traffic can simply be forwarded natively and handled by a PITR is not a solution unless there are practical PITRs with enough capacity. The fundamental problem of data-plane/FIB scaling remains the same. In addition, if there were no IPv6 connectivity available to the ITR, it could not do native forwarding with hopes of reaching a PITR. It's a good thing IPv6 will probably be deployed everywhere long before LISP is a practical concern, but this exemplifies the fact that the current design of LISP may not be able to live up to its promise of an all-purpose encapsulation scheme able to carry any protocol within the outer-headers, without native support for that protocol/AF to the site. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From Fred.L.Templin@boeing.com Mon Jul 25 14:34:22 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1868011E80C0 for ; Mon, 25 Jul 2011 14:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfJefv3zq5GU for ; Mon, 25 Jul 2011 14:34:21 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 79F9811E80AC for ; Mon, 25 Jul 2011 14:34:21 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6PLYE6o023110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jul 2011 14:34:19 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6PLYDq4012416 for ; Mon, 25 Jul 2011 16:34:13 -0500 (CDT) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6PLXwEl011900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 25 Jul 2011 16:34:13 -0500 (CDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 25 Jul 2011 14:34:07 -0700 From: "Templin, Fred L" To: "lisp@ietf.org" Date: Mon, 25 Jul 2011 14:34:06 -0700 Thread-Topic: [lisp] uRPF as a possible solution Thread-Index: AcxLDWIwz68It/wuRdKtuMqNPxxAfQABA2gQ Message-ID: References: <20110725204019.9DEEC18C0D9@mercury.lcs.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:34:22 -0000 Just as a point of differentiation, LISP is trying to do map-and-encaps over the wide area, whereas IRON is doing it within a bounded organization with native Internet routing over the wide area. So, LISP is an "inter-site" map-and-encaps system where IRON is an "intra-site" system (for some definition of "site"). I think some of the issues being discussed here are exacerbaed by that design departure. Thanks - Fred = From dino@cisco.com Mon Jul 25 14:49:46 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4553111E80CC for ; Mon, 25 Jul 2011 14:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMXXkZZaDfjt for ; Mon, 25 Jul 2011 14:49:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 802AE11E80C7 for ; Mon, 25 Jul 2011 14:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=2287; q=dns/txt; s=iport; t=1311630585; x=1312840185; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AP5XYCfMHcjjsFwWtCtVsh8tNKXz4ruw1OJDvW8reS0=; b=d6wlOl4C/tj1YqQdqVtT/rBeaMdquHncOZ7R39ygRjGFZ2dtLqBiuLSp b8P39tFWBPQc7p2cPP3ZHLQ1TcEdANd3EkuDbNpFDb9YEaKScqnJO/UNI owDJxz+b7eKUJ0ndtNHn59SNzC/75/vuaF7eApOsEjjOci3qRZtijGcvC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALXkLU6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBEQFlAgkFDAwOCjoUGDkHFyAHpzR3iHwEokaeOYVgXwSHVYsbkQA X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6273256" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2011 21:49:44 +0000 Received: from sjc-vpn7-2036.cisco.com (sjc-vpn7-2036.cisco.com [10.21.151.244]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6PLniUv009713; Mon, 25 Jul 2011 21:49:44 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 14:49:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03EE9589-6BB0-4DF5-B941-BF9D4021974E@cisco.com> References: <20110725204019.9DEEC18C0D9@mercury.lcs.mit.edu> To: Jeff Wheeler X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:49:46 -0000 Guys, if you want to throw around solutions and brainstorm on the list, = you need to be open minded. We are not proposing anything, we are = discussing pros and cons of possible ways to solve problem. Do not take = this as "how LISP solves the problem". We have lots of options, but = understand how they cannot be perfect. Hence, why they are not documented right now. Dino On Jul 25, 2011, at 1:56 PM, Jeff Wheeler wrote: > On Mon, Jul 25, 2011 at 4:40 PM, Noel Chiappa = wrote: >> I'm not so sure - a small/medium size site might have two ITRs (or a = small >> number of them), and in those cases responsbility for covering the = address >> space could be divided between them, but many smaller sites will only = have one >> (their exit router). >=20 > I agree. However, if the solution for ITR cache churn is to "Hail > Mary" the packets up to the native Internet (assuming native > connectivity for that Address Family is even available) then these > packets must find their way to an xTR that can handle the traffic, or > they will be dropped. This must be the very powerful router (or > cluster) that some have mentioned -- but you have to be able to build > and sell it at practical size, power/heat properties, and price. >=20 > So saying this traffic can simply be forwarded natively and handled by > a PITR is not a solution unless there are practical PITRs with enough > capacity. The fundamental problem of data-plane/FIB scaling remains > the same. In addition, if there were no IPv6 connectivity available > to the ITR, it could not do native forwarding with hopes of reaching a > PITR. It's a good thing IPv6 will probably be deployed everywhere > long before LISP is a practical concern, but this exemplifies the fact > that the current design of LISP may not be able to live up to its > promise of an all-purpose encapsulation scheme able to carry any > protocol within the outer-headers, without native support for that > protocol/AF to the site. >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@uclouvain.be Mon Jul 25 14:58:38 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37721F886D for ; Mon, 25 Jul 2011 14:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3zEOucKXxqi for ; Mon, 25 Jul 2011 14:58:38 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1576C21F885C for ; Mon, 25 Jul 2011 14:58:38 -0700 (PDT) Received: from [IPv6:2001:df8::8:226:bbff:fe0e:882c] (unknown [172.17.0.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dsaucez@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 2C6DA11E249; Mon, 25 Jul 2011 23:58:32 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 2C6DA11E249 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1311631114; bh=tLo6rmqzqrBuiz4HLpn4FPwV+8gV/uxzY8dYKkIUzOM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wt+l3MpHeKtuipdSFFHpfFdGDIUD/2hwcE2VRSnNEkP5EYUo/CGmJGEHRvKOfX+IX ouInemsfJ3jYz8zdVAQVSmHgX8Vv2Mrj8OfKblyeR7ryzrJHu5D+90ekZ7LF0DISEi oKBfx9nBB/UEjKmtkFpihqeGBF7DBhfpTdwTPNT8= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <43E284F4-BE99-4D7B-8DAD-70E307A665D9@cisco.com> Date: Mon, 25 Jul 2011 17:58:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> <43E284F4-BE99-4D7B-8DAD-70E307A665D9@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 2C6DA11E249.A1101 X-SGSI-MailScanner: Found to be clean X-SGSI-From: damien.saucez@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 21:58:39 -0000 On 25 Jul 2011, at 15:42, Dino Farinacci wrote: >> On Mon, Jul 25, 2011 at 3:26 PM, Dino Farinacci = wrote: >>> Darrel has already mentioned that the ITR can = "forward-on-cache-miss" by default if the implementation wants to = protect its cache. >>=20 >> How can these packets arrive at their destination? >=20 > If destined to non-LISP sites, they go natively, just like they would = in a router today. If destined for LISP sites and sent natively because = you don't want to store the locator-set for the site (due to the cache = filling up), they go natively and will hit the closest PITR which will = encapsulate to the destination LISP site. >=20 If you are using ALT, you can also imagine that the PITR will = "pre-fetch" the EID mappings for "all" the EID prefixes announced on the ALT. You thus have mappings for "all" the potential EID. For this kind of PITR, the = only limit is the price of the box, but you can have distribution or = hierarchy of such PITRs: a CDN of PITR :-D Damien Saucez > Dino >=20 >>=20 >> --=20 >> Jeff S Wheeler >> Sr Network Operator / Innovative Network Concepts >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Jul 25 15:02:21 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F421F8AFE for ; Mon, 25 Jul 2011 15:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=-1.596, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBhxWcW9VgIi for ; Mon, 25 Jul 2011 15:02:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0C21F8AD6 for ; Mon, 25 Jul 2011 15:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=5758; q=dns/txt; s=iport; t=1311631340; x=1312840940; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QOHS9cyFJgyiur27XfT3l+J+w6qfHJDCF7a0F4rkLX8=; b=Blw7JISpo57jK8tOUyriYXq/XNaUnc1Tht4mWUOAnw3aX/yERrKWKeId BTbFp4iUhyi/XqiP8/BFzFh12fkF3M+zgQJ5QuyQWfLUDS4xmOULBKxWZ GFehDFlJYnpIsVSu8GQ039Sb8GfjEsptjDPaGmxOJZ0eBZ9H9l8QmXm0Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA/nLU6rRDoG/2dsb2JhbAA0AQEBAQIBFAFwBQwMDkQUUQc3B6c0d4h8olKeOYVgXwSHVYsbkQA X-IronPort-AV: E=Sophos;i="4.67,265,1309737600"; d="scan'208";a="6276068" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2011 22:02:19 +0000 Received: from sjc-vpn7-2036.cisco.com (sjc-vpn7-2036.cisco.com [10.21.151.244]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6PM2IhQ022239; Mon, 25 Jul 2011 22:02:18 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Dino Farinacci In-Reply-To: Date: Mon, 25 Jul 2011 15:02:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> To: Patrick Frejborg X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 22:02:21 -0000 >>> the time of the reply from the mapping system must be shorter than = it >>> takes for the SYN packet to become an ACK packet. If not, then the = xTR >>> needs to store the packet in memory (which is expensive at higher >>> speeds) or drop it but we have to assume that valid traffic have >>> already been dropped or delayed at the ingress ITR. So doing that a >>=20 >> Right, so you have some hard decisions to make. The ETR can do lookup = in its cache to figure out if the (source-RLOC, source-EID) is in its = cache and if not, drop the packet, then do a lookup so subsequent = packets can have the cache populated so the check can pass. >>=20 >> I would prefer to not propose this solution. I'd rather try to solve = on the ITR and make the solution closer to the source. >>=20 >=20 > Me either, no cache and mapping functionality at the ETR but instead > have a quick look at the incoming packets so that ITR doesn't have to > fetch the information from a very slow memory (e.g. hard disk). > Assumption here is that there is a local database at the ITR - but > that is not the case in current I-Ds, this is an option but it has > other problems=85 It is described or else the ITR does not know how to set = locator-status-bits. >>> second time is not helpful. Also the mapping system must always >>> respond promptly to an ITR, if there are several ITRs using the same >>> server how to ensure that an ITR under attack gets priority so that >>> the mapping requests are further delayed (apart from the light of >>> speed issue). >>=20 >> Agree, but these issues are no different than what we see in the DNS = today. It is too hard and won't scale to differentiate and if anyone = tries to figure a solution to this bit, it probably can't work. >>=20 >=20 > There is a huge difference between a DNS and a MS lookup, DNS is not > in the forwarding plane at all but to build forwarding plane in LISP > you need to ask the MS on how to build it - the forwarding plane is There is not a huge difference, the rate of incoming requests is what is = the difference. And if data-plane induced Map-Requests are rate-limited = to the same rate a control-plane protocol, like DNS, is being used, it = is exactly the same. > not prepared in advance. And if the MS system is fair away or can't > reply to the requests at the same pace as the bogus ITR sends packets The draft talks about how to pace. And if a DNS server can't reply = because of the 1,000,000 requests coming to it from 1,000,000 places, = you won't get your TCP connection established too. >>=20 >>> Then if LISP gets widely deployed there is the botnet issue with >>> clients at dispersed EID prefixes, these will not be caught by a = uRPF >>> filter but they could generate a lot of cache entries depending on = how >>> many +/- mappings each EID prefix provides. >>=20 >> That is why you solve it at the encapsulator end of this so you don't = have to query the mapping database *for your own EID-prefixes*. The ITR = has all the information it needs locally to determine to pass a packet = from a source or not. >=20 > For the first case, i.e. an attacker using a fake ITR - the attacker > owning the fake ITR(s) will not do that :-) And you can't stop me bombarding your home router with packets. There = are some solutions that can help some situations but you are not going = to find a silver bullet. > The second case is far in the future, LISP has been deployed and well > established. Imagine if you have 200 000 botnet clients, each client > is attached to their dedicated EID prefix and each client generates > 1-10 +/- mappings per EID prefix. Now the botnet admin decides that a What does that mean? Each EID-prefix is one mapping so what are you = saying "10 per EID-prefix". > EID site will be attacked, he triggers a timestamped HTTP request to > that EID site, a SYN goes out at the very same seconds from 200 000 > botnet clients. No fake source/destination are used, all EIDs are What makes you think 200,000 requests will hit the same map-server and = ETR at the same time?=20 If you frame a problem to your advantage, all my answer is going to be = is "packets will get dropped". And that is goodness. If we rate-limite, = 200 botnets will get map-replies and 10% of good clients will get = service. It is not LISP that causes this problem, it is the rate the ETR can = receive and process packets.=20 > legal and they don't get caught by uRPF. But the ITR (handling the > ACKs from the attacked EID site) has to create somewhere between 200 > 000 to 2 millions cache entries at a pace that depends on how powerful So the xTR can handle 200,000 incoming requests but can't cache 2 = million entries? How does that exactly work? > server/servers are used to generate the 200 000 ACKs. And if there is > no local database at the ITR (that is handling the ACKs) it has to I am not following, you logic is not making any sense. > consult the MS, resolve each entry and that will take some time. And > if the cache size is limited, you need adjust the timers and flush the > cache more often, but then the attacker can do this trick more often. Who says you should flush the cache. > After a while, when there is analyzed data, you could create a > blacklist at the ITR (that is handling the returning ACKs). The > numbers used here are taken from nowhere, I had to use some numbers to > explain the possible scenario that could happen in the future. No, no, no. I don't know where to start to reply to this. I can't = actually because I don't understand the sequence and believe it = contradicts itself. Dino >=20 > Patrick From darlewis@cisco.com Tue Jul 26 07:44:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC721F8CCF for ; Tue, 26 Jul 2011 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=-1.673, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqxy+ieVxmHz for ; Tue, 26 Jul 2011 07:44:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18721F8CB6 for ; Tue, 26 Jul 2011 07:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=610; q=dns/txt; s=iport; t=1311691492; x=1312901092; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UDt4pY6HV5nHIPCuarjS2iPWKFGBzvLYHZzGOKLnPQg=; b=JQ96d0zkaseosxzE1S9cjIUvoQRuiEWULmma804Us6T7LR6elOhqXvvs fous+Jag9Zko8s0FaDHKiUhKKKIlhMKLEVHvnJZO1GmWPlITzO0d6GlES WxEt12Zfv2WE+9yoWcv0d8MFVOM0o+xO9rX8CdTwswO71SKuoEc69RCHJ 0=; X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6507972" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 14:44:51 +0000 Received: from [10.21.75.55] ([10.21.75.55]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6QEipNb003161; Tue, 26 Jul 2011 14:44:51 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Darrel Lewis In-Reply-To: Date: Tue, 26 Jul 2011 07:44:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03FE4BB6-1DED-4DB2-9ADD-E92821774E2D@cisco.com> References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> <1DE8F029-92A0-4CC8-BD30-CB795E5797A5@cisco.com> <33FB0D8A-5934-4BEB-8D63-9E0F9884E621@cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1244.3) Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:44:53 -0000 On Jul 25, 2011, at 12:39 PM, Jeff Wheeler wrote: > On Mon, Jul 25, 2011 at 3:26 PM, Dino Farinacci = wrote: >> Darrel has already mentioned that the ITR can "forward-on-cache-miss" = by default if the implementation wants to protect its cache. >=20 > How can these packets arrive at their destination? >=20 If they were destined non-LISP, they will get there like normal. = (forward would have been your action anyway) If they were destined to LISP, they might end up on a PITR some where = that already has a mapping, and then delivered to a destination ETR. -Darrel= From pfrejborg@gmail.com Tue Jul 26 07:52:16 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139E521F8CB9 for ; Tue, 26 Jul 2011 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yW1FpubuDFg for ; Tue, 26 Jul 2011 07:52:15 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49221F8CB8 for ; Tue, 26 Jul 2011 07:52:14 -0700 (PDT) Received: by ewy19 with SMTP id 19so567209ewy.31 for ; Tue, 26 Jul 2011 07:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YrD3OLTFj0bhHuhqPWJEgNI0TrFyp2Q3Ca2RGY9G52Q=; b=JwyVeyJ4BWgiZisllNNKeV+E9m79JJeSIEwcLrEO9FfmLzWY28/wu9pwiGl25w7MnX LEOqStEbljRCZVaOVc1gTfjnR8gFT1l0V4XmWs+L8wxDMy5U0NV20SNtvbSakwDqp3NR U+YFRBfXr/ccvQfOvtw1p/8PLS/YO0hYhHIJU= MIME-Version: 1.0 Received: by 10.213.14.145 with SMTP id g17mr1039415eba.12.1311691932072; Tue, 26 Jul 2011 07:52:12 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Tue, 26 Jul 2011 07:52:11 -0700 (PDT) In-Reply-To: References: <0BA0E578-FD46-4D3E-A6B4-32B92706AF1F@cisco.com> <3E9123A3-9674-4B07-BAA5-AD027106A1D5@cisco.com> <89CCFBEC-79E3-454B-A5C7-C34DBE5629D5@cisco.com> <8B0C33C2-6663-4AF2-8A74-0862E09A1C09@cisco.com> Date: Tue, 26 Jul 2011 17:52:11 +0300 Message-ID: From: Patrick Frejborg To: Dino Farinacci Content-Type: text/plain; charset=ISO-8859-1 Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:52:16 -0000 On Tue, Jul 26, 2011 at 1:02 AM, Dino Farinacci wrote: > No, no, no. I don't know where to start to reply to this. I can't actually because I don't understand the sequence and believe it contradicts itself. I'll start over and skip the first case, and trying to simplify my questions/concerns in parts. Let me first describe the environment to check that I have understood LISP correctly. We are in the future and LISP has been deployed. There are residences that have IPv6 in their local networks but the DFZ is still only using IPv4, then there is one content site (providing IPv6 based services) that the residences are reaching by using LISP. The packet flow goes as following (jump in where I get lost): The ITR at the residence (hereafter called rITR) receives a packet from the local network, there is no entry in the cache for the destination and thus it consults the MS. The rITR receives a reply from MS, creates the cache entry and adds the LISP header to the packet and the encapsulated packet is routed to the ETR of the content site (cETR). The cETR removes the LISP header and the packet is routed to the server of the content site. Since this is a valid connection, the server replies and the packet is routed to the ITR of the content site (cITR), No cache entry exists, thus the cITR is consulting the MS, a reply is received, a cache entry is created at the cITR and the returning packet gets encapsulated and routed over DFZ to the ETR taking care of the residence (rETR). The rETR removes the LISP header and the session is established. If I got it so far right, we can proceed to the next step - if not, stop reading There is an event - there are about 200 000 residences behind rITRs (no residence shares an rITR) that want to buy a ticket from the content site at a certain day and time. Thus these residences logs into the server at the content site slightly before the ticket sale begins. For DNS and rITR lookup at MS there are no issues, the distributed DNS cache architecture prevents that authoritative DNS server doesn't get all requests - and I guess that is similar for the MS. No issues exists at the cETR either. But for the returning packets at the cITR I have _questions_. For returning packets there is no need to do DNS lookups but if I have understood LISP correctly the cITR needs to do MS lookups so that returning packets gets routed back to the residences. If the cITR uses only one MS server there will be intensive traffic between the cITR and the MS server - and I think the cache mechanism used in DNS can not be applied here, right?? Also the MS server and cITR aren't necessary located in the same premises, the round trip delay between cITR and MS most likely will have an impact on the time it takes to build 200 000 new cache entries. And if the MS provider has installed a bad performing MS server then that will further have an impact on how fast the cITR's cache is built. The status of my forwarding plane is no longer solely in my hands. The major difference with today's architecture is that there is no need to do a lookup in DNS for returning traffic, thus we cannot completely compare DNS and MS scalability - I think there is a new pattern in MS that doesn't exist in DNS, but I might have it wrong. If the cITR cache doesn't scale enough and I would prefer to add a second cITR (instead of using the PITR) to deal locally with my cache issues. How do I ensure that the returning packets are routed to the correct cITRs? No changes is applied on the server stack and thus there is a 0/0 route at the server pointing to one next-hop. Should I install a server load balancer in front of the two cITRs to fix this? Patrick From jnc@mercury.lcs.mit.edu Tue Jul 26 08:38:07 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E04811E8120 for ; Tue, 26 Jul 2011 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOJEMY25EWbU for ; Tue, 26 Jul 2011 08:38:06 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BD54611E8119 for ; Tue, 26 Jul 2011 08:38:06 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A7E2B18C0F1; Tue, 26 Jul 2011 11:38:05 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110726153805.A7E2B18C0F1@mercury.lcs.mit.edu> Date: Tue, 26 Jul 2011 11:38:05 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:38:07 -0000 > From: Patrick Frejborg > The ITR at the residence ... receives a packet from the local network, > there is no entry in the cache for the destination and thus it consults > the MS. Technically (unless by "MS" you meant 'Mapping System', but the acronym MS is usually expanded to 'Map-Server'), it consults its Map-Resolver ('MR'), and the MR (through means opaque to the average client, but at the moment its the ALT) consults the MS on the ITR's behalf. > The rITR receives a reply from MS, creates the cache entry and adds > the LISP header to the packet An ITR _can_ buffer packets until the mapping arrives, but not necessarily: other options are i) forward them through a PITR, or ii) drop them. > the packet is routed to the ITR of the content site (cITR), No cache > entry exists Unless a mapping has been gleaned (which I personally think ought to be done at cETRs, otherwise the cITR will have to go through a resolution cycle - although there are a number of ways this could happen [and I don't recall what the spec does at the moment],, e.g. when the rITR has to do the lookup, it can make sure the matching mapping is intalled at the destination). > a reply is received, a cache entry is created at the cITR and the > returning packet gets encapsulated Same comment as above about the rITR. > For returning packets there is no need to do DNS lookups but if I have > understood LISP correctly the cITR needs to do MS lookups so that > returning packets gets routed back to the residences. If the cITR uses > only one MS server there will be intensive traffic between the cITR and > the MS server As mentioned above, I favour some sort of 'piggybacking' (an class of optimization used in a number of places in LISP) to prevent this by 'pre-loading' the mapping into the cITR's cache, although I'm more concerned about delay/etc than the server load (although that of course is an issue too, but only in some circumstances, like the one you outline, whereas delay is always an issue). > The major difference with today's architecture is that there is no need > to do a lookup in DNS for returning traffic Correct - this is the big architectural difference, hence my desire to get rid of the mapping lookup in the reverse direction. (I had a great way to do this in a secured way in CONS, but alas we aren't using CONS.) > If the cITR cache doesn't scale enough and I would prefer to add a > second cITR .. How do I ensure that the returning packets are routed to > the correct cITRs? This is a great question/engineering issue, and one that has been extensively discussed in the past. There is no great, easy, solution. Even if one can provide the 'return' mapping to the ingress cETR (above), what happens if that's not the same box as the cITR? One either i) has to work out a way to make sure it is the same box (not trivial), or ii) pass the mapping to the box that will be the cITR (not trivial), or iii) give up on optimizing out the lookup cycle in the return direction (not acceptable, IMO). In other words, the engineering details of large sites remain to be fully worked. Noel From pfrejborg@gmail.com Thu Jul 28 00:32:20 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196D421F851A for ; Thu, 28 Jul 2011 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU8RCybf+b4T for ; Thu, 28 Jul 2011 00:32:19 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18D21F8B89 for ; Thu, 28 Jul 2011 00:32:19 -0700 (PDT) Received: by eya28 with SMTP id 28so3041496eya.21 for ; Thu, 28 Jul 2011 00:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g9sGcT7eCu5ZWCsc2RTMcH3j0mMVDB4Efglr3O54jKg=; b=d+/pD7syhwTLDBmln8Jbp+Z194XlKB2mbzErfR/EVk74QxnyHc8WYOpKW2sldu6YsG +D45vjyslNIl/PWnm4/59NtROTSuSLpkHz/07ETURCjwbPKQDvtt/MT0vPVz4Oqu5z4L hDoSDgHrEyGOmwRJpVyux+Itkn50yaI4Gtbyg= MIME-Version: 1.0 Received: by 10.213.27.198 with SMTP id j6mr282696ebc.88.1311838338277; Thu, 28 Jul 2011 00:32:18 -0700 (PDT) Received: by 10.213.102.4 with HTTP; Thu, 28 Jul 2011 00:32:18 -0700 (PDT) In-Reply-To: <20110726153805.A7E2B18C0F1@mercury.lcs.mit.edu> References: <20110726153805.A7E2B18C0F1@mercury.lcs.mit.edu> Date: Thu, 28 Jul 2011 10:32:18 +0300 Message-ID: From: Patrick Frejborg To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 07:32:20 -0000 On Tue, Jul 26, 2011 at 6:38 PM, Noel Chiappa wro= te: > =A0 =A0> For returning packets there is no need to do DNS lookups but if = I have > =A0 =A0> understood LISP correctly the cITR needs to do MS lookups so tha= t > =A0 =A0> returning packets gets routed back to the residences. If the cIT= R uses > =A0 =A0> only one MS server there will be intensive traffic between the c= ITR and > =A0 =A0> the MS server > > As mentioned above, I favour some sort of 'piggybacking' (an class of > optimization used in a number of places in LISP) to prevent this by > 'pre-loading' the mapping into the cITR's cache, although I'm more concer= ned > about delay/etc than the server load (although that of course is an issue > too, but only in some circumstances, like the one you outline, whereas de= lay > is always an issue). I agree with you, it would be nice to be able to pre-load the database to the cITR, the delay is the bigger issue since for the returning traffic is "one to many sites" lookup and hence the cache mechanism might not be as efficient as in DNS. But taking that approach, the mapping system would look more like BGP than DNS. > > =A0 =A0> The major difference with today's architecture is that there is = no need > =A0 =A0> to do a lookup in DNS for returning traffic > > Correct - this is the big architectural difference, hence my desire to ge= t > rid of the mapping lookup in the reverse direction. (I had a great way to= do > this in a secured way in CONS, but alas we aren't using CONS.) > > =A0 =A0> If the cITR cache doesn't scale enough and I would prefer to add= a > =A0 =A0> second cITR .. How do I ensure that the returning packets are ro= uted to > =A0 =A0> the correct cITRs? > > This is a great question/engineering issue, and one that has been extensi= vely > discussed in the past. There is no great, easy, solution. Even if one can > provide the 'return' mapping to the ingress cETR (above), what happens if > that's not the same box as the cITR? One either i) has to work out a way = to > make sure it is the same box (not trivial), or ii) pass the mapping to th= e > box that will be the cITR (not trivial), or iii) give up on optimizing ou= t > the lookup cycle in the return direction (not acceptable, IMO). In other > words, the engineering details of large sites remain to be fully worked. > Think we have to live the lookup cycle in the return direction so that uRPF can be used to prevent DoS and cache trash. But it might cause delays for returning packets due to an event - this "ticket sale" event can be created by a botnet admin if he has enough clients behind rITRs and directed towards any content site. Thus the lookup cycle for returning traffic is not only an issue for larger content sites but also for all business critical content sites (today multi-homed content sites). The risk of lookup cycle delay can be mitigated if the server stack is upgraded, if that would be possible then the content site admin has a choice. Patrick From jsw@inconcepts.biz Thu Jul 28 08:42:48 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554EF21F8CA2 for ; Thu, 28 Jul 2011 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHtBuU5DO+tA for ; Thu, 28 Jul 2011 08:42:47 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 489EC21F8C23 for ; Thu, 28 Jul 2011 08:42:46 -0700 (PDT) Received: by vws18 with SMTP id 18so3878083vws.27 for ; Thu, 28 Jul 2011 08:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.202.1 with SMTP id fc1mr42013vcb.196.1311867765603; Thu, 28 Jul 2011 08:42:45 -0700 (PDT) Received: by 10.220.4.193 with HTTP; Thu, 28 Jul 2011 08:42:45 -0700 (PDT) X-Originating-IP: [96.28.65.39] In-Reply-To: References: <20110726153805.A7E2B18C0F1@mercury.lcs.mit.edu> Date: Thu, 28 Jul 2011 11:42:45 -0400 Message-ID: From: Jeff Wheeler To: lisp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:42:48 -0000 On Thu, Jul 28, 2011 at 3:32 AM, Patrick Frejborg wro= te: > delays for returning packets due to an event - this "ticket sale" > event can be created by a botnet admin if he has enough clients behind > rITRs and directed towards any content site. Thus the lookup cycle for I would like everyone to keep in mind that the "botnet clients" or malicious traffic does not need to originate from LISP sites. A motivated attacker will send crafted packets directly to the Internet with a LISP outer-header and false source address in the inner-header. I am not sure it is even relevant if the malicious site(s) are subject to BCP-38/uRPF/etc by their service provider. > returning traffic is not only an issue for larger content sites but > also for all business critical content sites (today multi-homed > content sites). I think we are all on the same page now. I'm glad the discussion has moved from one where it was thought that only super-huge content sites would need to address this scaling problem, to folks agreeing that every mission-critical site must do so. --=20 Jeff S Wheeler Sr Network Operator=A0 /=A0 Innovative Network Concepts From jnc@mercury.lcs.mit.edu Thu Jul 28 09:15:26 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E0911E8080 for ; Thu, 28 Jul 2011 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.118 X-Spam-Level: X-Spam-Status: No, score=-6.118 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRazECTgab4k for ; Thu, 28 Jul 2011 09:15:26 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id ED28811E8074 for ; Thu, 28 Jul 2011 09:15:24 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 57F4D18C0A5; Thu, 28 Jul 2011 12:15:24 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110728161524.57F4D18C0A5@mercury.lcs.mit.edu> Date: Thu, 28 Jul 2011 12:15:24 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:15:26 -0000 > From: Patrick Frejborg > But taking that approach, the mapping system would look more like BGP > than DNS. Yes and no. For _most_ sites, no, since their access patterns (even for servers) are to a limited share of the Internet, therefore much less than a full table. Also, BGP (like any 'push' system) distributes _everything_ to _everyone_, regardless of whether they need it or not. Any data at any ITR (even if it's a cITR at a content provider, with lots of data) is there because it is _actually going to be used_. Yes, for cITRs, it will be a lot of data. But TANSTAAFL - separating location and identity is going to have some costs, to go along with all the benefits it provides. And an alternative 'clean-sheet' architecture might have slightly better distribution of those costs (i.e. without point loads such as a cITR), but then you have the 'cost' of a forklife upgrade to everything in the network - and we know from experience that doesn't succeed very well. I do expect people will come up with some way of partitioning the mapping state to get rid of large point loads (e.g. through parallel cITRs at large sites). Let's not forget that _any_ location/identity separation system (which there is general consensus we have to have) is going to have to have roughly the same amount of mapping state, so it's not like there's some magic dust that can make the problem go away entirely... > Think we have to live the lookup cycle in the return direction so that > uRPF can be used to prevent DoS and cache trash. I don't understand the issue there, but in any case, speaking of the need for a lookup cycle, I do think that there is almost certainly a way to do some sort of piggyback to cut out the lookup cycle _delay_ (although of course the return mapping will have to be provided to the server ITR in some manner). It's just a matter of working out how to do it... >> give up on optimizing out the lookup cycle in the return direction >> (not acceptable, IMO). > the lookup cycle for returning traffic is not only an issue for larger > content sites but also for all business critical content sites No disagreement - hence my statement that "[not] optimizing out the lookup cycle in the return direction [is] not acceptable, IMO". Noel From jari.arkko@piuha.net Fri Jul 29 13:25:53 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F411E808D for ; Fri, 29 Jul 2011 13:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szv82mgx2S4j for ; Fri, 29 Jul 2011 13:25:49 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51F5E8011 for ; Fri, 29 Jul 2011 13:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 289C02CEFF; Fri, 29 Jul 2011 23:25:13 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-A1rVWaI8KI; Fri, 29 Jul 2011 23:25:12 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 192132CC4B; Fri, 29 Jul 2011 23:25:11 +0300 (EEST) Message-ID: <4E331727.8000503@piuha.net> Date: Fri, 29 Jul 2011 16:25:11 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: lisp@ietf.org, draft-ietf-lisp-lig@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] AD review of draft-ietf-lisp-lig X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:25:53 -0000 Thanks for sending me a few documents to read :-) I'm starting with an easy one. This document is ready to move forward, I found no technical issues but I did find a few editorial issues. I have sent the draft forward to an IETF last call. Technical: None Editorial: Section 1 gives the usual RFC 2119 terminology, but I don't actually see why this draft would need to use these terms. This is an explanation of a tool that is based on Lisp protocols defined in other documents, right? Please delete section 1. Also, please reformulate the definition of term "EID" so that it does not use the RFC 2119 keywords; a definition seems like the wrong place to use such keywords, and in case, the normative rules about the EIDs should probably only exist in one of the Lisp documents. > ITR, ETR, PA addresses, xTR These terms are not defined in this document. Please add them and possibly other missing terms to the terminology section (or just expand them on first use and refer to a document that defines them). > Sending Map-Requests to Map Resolvers provides a secure > mechanism mechanism to obtain a Map-Reply containing the > authoritative EID-to-RLOC mapping for a destination LISP site. > s/mechanism mechanism/mechanism/ > an EMR is a Map-Request message > which is encapsulated with another LISP header using UDP > destination port number 4341 Please refer to the Lisp header specification and the one that defines port 4341. > The cisco LISP prototype implementation has support for lig for IPv4 s/cisco/Cisco/g (I think) > titanium-simlo# lig self6 > Send loopback map-request to 10.0.0.1 for 192:168:1:: ... > Received map-reply from 10::1 with rtt 0.044372 secs > > Map-cache entry for EID 192:168:1::: > 192:168:1::/48, uptime: 00:00:01, expires: 23:59:58 > via map-reply, self > Locator Uptime State Priority/Weight Packets In/Out > 10.0.0.3 00:00:01 up 1/100 0/0 > 10::1 00:00:01 up 2/0 0/0 > What are the 192:168:1 etc addresses? Would it be better to use the IPv6 example address space for these examples? Jari From jari.arkko@piuha.net Fri Jul 29 13:46:33 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD721F8B89 for ; Fri, 29 Jul 2011 13:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx7-nAhiV2ke for ; Fri, 29 Jul 2011 13:46:33 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1053521F8B4D for ; Fri, 29 Jul 2011 13:46:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 580262CEFF; Fri, 29 Jul 2011 23:46:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBluCTrlLdmY; Fri, 29 Jul 2011 23:46:01 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 848A22CC4B; Fri, 29 Jul 2011 23:46:01 +0300 (EEST) Message-ID: <4E331C08.9060001@piuha.net> Date: Fri, 29 Jul 2011 16:46:00 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: lisp@ietf.org, draft-ietf-lisp-lig@tools.ietf.org References: <4E331727.8000503@piuha.net> In-Reply-To: <4E331727.8000503@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] AD review of draft-ietf-lisp-lig X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:46:33 -0000 I forgot to say that if you have a possibility to fix the editorial issues, please issue a new draft (even if the last call is starting/started). Jari From iesg-secretary@ietf.org Fri Jul 29 14:15:05 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40D121F8BB3; Fri, 29 Jul 2011 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzsdxp22H5ab; Fri, 29 Jul 2011 14:15:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125BA21F8B69; Fri, 29 Jul 2011 14:15:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110729211505.22696.24829.idtracker@ietfa.amsl.com> Date: Fri, 29 Jul 2011 14:15:05 -0700 Cc: lisp@ietf.org Subject: [lisp] Last Call: (LISP Internet Groper (LIG)) to Experimental RFC X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 21:15:05 -0000 The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP Internet Groper (LIG)' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-lig/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-lig/ No IPR declarations have been submitted directly on this I-D. From pfrejborg@gmail.com Sat Jul 30 07:37:51 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3521F88DD for ; Sat, 30 Jul 2011 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmGnVAi1hwRp for ; Sat, 30 Jul 2011 07:37:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27621F889A for ; Sat, 30 Jul 2011 07:37:50 -0700 (PDT) Received: by wwe5 with SMTP id 5so2917115wwe.13 for ; Sat, 30 Jul 2011 07:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QcZE97RfqVTlD5oDIXCHSQVWOLyzDdNAdhKzsQOakwQ=; b=FTlrW2RTRJyjPUc4Law4BXegT8x0381COhyEIkKwjffsNiAWWlrGce8v88+OMDbmhC e1bt9HLYSjg4NthumDG3Pnjv1Oc7Qz7eZSqDdfcbNRzmCO56IJ4LnhUmfDauvV5W1nCd 5IWk/k1ZVndA68npSFH+s/TTFXl3rb5CWGPAM= MIME-Version: 1.0 Received: by 10.227.29.150 with SMTP id q22mr3467369wbc.78.1312036670252; Sat, 30 Jul 2011 07:37:50 -0700 (PDT) Received: by 10.227.2.143 with HTTP; Sat, 30 Jul 2011 07:37:50 -0700 (PDT) In-Reply-To: <20110728161524.57F4D18C0A5@mercury.lcs.mit.edu> References: <20110728161524.57F4D18C0A5@mercury.lcs.mit.edu> Date: Sat, 30 Jul 2011 17:37:50 +0300 Message-ID: From: Patrick Frejborg To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: lisp@ietf.org Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 14:37:51 -0000 On Thu, Jul 28, 2011 at 7:15 PM, Noel Chiappa wrote: > Yes and no. For _most_ sites, no, since their access patterns (even for > servers) are to a limited share of the Internet, therefore much less than a > full table. Also, BGP (like any 'push' system) distributes _everything_ to > _everyone_, regardless of whether they need it or not. Any data at any ITR > (even if it's a cITR at a content provider, with lots of data) is there > because it is _actually going to be used_. > Believe you are saying that DNS-stylish distribution for rITRs and BGP-stylish distribution for cITRs,... > Yes, for cITRs, it will be a lot of data. But TANSTAAFL - separating location > and identity is going to have some costs, to go along with all the benefits > it provides. And an alternative 'clean-sheet' architecture might have > slightly better distribution of those costs (i.e. without point loads such as > a cITR), but then you have the 'cost' of a forklife upgrade to everything in > the network - and we know from experience that doesn't succeed very well. I > do expect people will come up with some way of partitioning the mapping state > to get rid of large point loads (e.g. through parallel cITRs at large sites). > > Let's not forget that _any_ location/identity separation system (which there > is general consensus we have to have) is going to have to have roughly the > same amount of mapping state, so it's not like there's some magic dust that > can make the problem go away entirely... > The Loc/ID split can be achieved in many ways and the different methods do not necessary compete with each other. LISP is a endpoint (host) identifier scheme and separates the location from identity but it is still providing a host-to-host centric architecture. Pretty much the same as we have today with regular IPv4 and forthcoming IPv6 architectures (which is basically the same as IPv4 but with a larger unidimensional address space) though LISP is providing more mobility. The host-to-host centric architecture is quite retro compared with the current requirements - when you design a data center network you end up with trying to break the host-to-host concept for the most important services by adding a middlebox solution (such as SLB, ADC or tweaking with DNS) in front of the real servers to achieve load balancing of traffic to several servers and also to provide greater availability. What we are trying to achieve here is a host-to-service architecture, but due to the current stack structure you have to implement kludges in the data center to achieve it. And they are expensive, imposing L2 connectivity between the data centers, and also to configure and troubleshoot SLBs, ADCs in large L2 domains is far from fun. And I don't see how the data center becomes easier to configure and troubleshoot by adding cITRs/cETRs in front of the SLBs/ADCs... If you dare to go after the stack (and the unidimensional address space) the data center network architecture can be simplified - read the SCAFFOLD paper but with a conceptual view mindset. You can make SCAFFOLD less "clean-sheet" and backwards compatible with the current architecture. Take the packet header structure from RFC 6306 and to get the service ID backwards compatible with current applications it is obvious that the format of the service ID needs to be 32 bit. Then the current applications, that are informed about the destination IP address from the stack API, are still getting a 32 bit value but this time it is not an overloaded IP address - instead the service ID is shown and that has nothing to do with the routing architecture whatsoever. This opens up the possibility to replace the current kludges with service routers (no caches) and the service routers can redirect the service request to available real servers at any location - no need to have L2 connectivity between real servers because if you use MPTCP/SCTP as the transport protocol the session can be moved from server to another server over L3 boundaries (the MPTCP token is a session identifier). The application at the initiator never sees the locators, the stack shows only the service ID towards the application. Most likely this will reduce the CAPEX and OPEX in data centers, it becomes more flexible because then you could add additional resources over L3 boundaries to take care of traffic peaks (fulfill the promises of Cloud Computing). It might be that the enterprises and very large content providers are interested in this kind of architecture and starts to invest in it - it should be cheaper than the current one and it is a lot more flexible and more stable, a combination that is hard to resist - it can also be made backwards compatible with existing deployments, so no forklift upgrade is required. And LISP is needed to get this transition started. Oh,and I think there will be much less state information in the routing subsystem, because some of the workload is shifted from the network to the endpoints and the transport protocol is pretty good on doing liveness detection. And a hole new world opens up, think we are only scratching on the surface yet... Patrick From jnc@mercury.lcs.mit.edu Sat Jul 30 08:51:42 2011 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC74221F881C for ; Sat, 30 Jul 2011 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpeI5GzNSY4i for ; Sat, 30 Jul 2011 08:51:37 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9B00421F87C6 for ; Sat, 30 Jul 2011 08:51:37 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0805018C100; Sat, 30 Jul 2011 11:51:35 -0400 (EDT) To: lisp@ietf.org Message-Id: <20110730155135.0805018C100@mercury.lcs.mit.edu> Date: Sat, 30 Jul 2011 11:51:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] uRPF as a possible solution X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 15:51:42 -0000 {I have to go out soon, but before I go, a quick answer to this part: the later part of your message - which is most interesting! - I will get to after I have had more time to think about it.} > From: Patrick Frejborg > On Thu, Jul 28, 2011 at 7:15 PM, Noel Chiappa > wrote: >> Yes and no. For _most_ sites, no, since their access patterns (even >> for servers) are to a limited share of the Internet, therefore much >> less than a full table. Also, BGP (like any 'push' system) distributes >> _everything_ to _everyone_, regardless of whether they need it or not. >> Any data at any ITR (even if it's a cITR at a content provider, with >> lots of data) is there because it is _actually going to be used_. > Believe you are saying that DNS-stylish distribution for rITRs and > BGP-stylish distribution for cITRs... Not really (although perhaps, now that I think it through - see below); let me try and say it more clearly: First: for _all_ sites (no matter what size a share of the 'complete' mapping table their access pattern means they have to have), any data at their ITR(s) is there because it is _actually going to be used_. This is unlike BGP, which, _for any machine which is not sending packets to every destination on the Internet_, it is receiving _some_ data it has no use for. Yes, for the few sites which have to have the entire table (or very close to it), they are i) not going to save any space, and ii) 'push' might be more efficient than 'pull' if you have to do have the entire database. But how many sites will that be, really? Which leads me to... Second: For _most_ sites, even some/many of those which _are_ serving content (i.e. not just clients), their access patterns are to a limited share of the Internet. This is driven by several forces, including language, etc. Take for example the traces used to drive the simulations done for caching effectiveness (in LISP and LISP-TREE - I'm too lazy to look up the titles, I can get them if you need them). One of those traces was for a very large university (Université Catholique de Louvain), with about 30K students and staff. Universities tend to host a lot of content - albeit content that's not as popular as Youtube! Still, one would expect the _access patterns_ to that data to be pretty widespread (with the internationalization of the knowledge 'industry'), even if the _volume_ is much lower. (Yes, as you turn up the amount of accesses, the pattern will spread a bit, as you get a bit of 'fill in', but it's not going to expand to the entire mapping 'table'.) However, I think the pattern shown in those traces (IIRC, maximum cache size was about 1/10th of the Internet) is going to hold for _most_ sites, including many/most content sites. It would be very interesting to look at the ecommerce site of a major retailer, and see if they have a similar pattern. For those selling actual physical things, I'll bet most would be similar (no matter how high the traffic volume), simply because most retailers have limited distributions networks (often limited to a single country, or a small number of countries) for the actual physical goods. There may be a few exceptions (maybe Amazon?), but they are the exception, I expect - and even then I doubt they are selling to the entire world/Internet. Yes, retailers for purely electronic goods (music, etc) would not have this limitations - but there are not many of them, compared to the others. Yes, the Youtubes, etc of the world are really going to be exceptions (and they are going to have to have almost full tables), but those sites already have very specialized infrastructure. Perhaps a hybrid 'push-pull' distribution for mapping data (as in, a deliberate load of the entire table, but pulled, rather than pushed, a la BGP) would be the way to go for them? But that is just speculation. (An interesting observation about terminology: 'push' and 'pull' can be broken down into two axes: i) 'how much', and ii) 'how'. What we normally divide into two - 'push' and 'pull' - are actually only two boxes out of the four defined by those orthogonal axes. I just referred to a third ('all' and 'retrieve'), and there is a fourth ('some' and 'send'), which I cannot think of any use for!) Noel