Re: [Ila] LISP for ILA

Tom Herbert <tom@quantonium.net> Tue, 06 March 2018 00:42 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349E12EAC9 for <ila@ietfa.amsl.com>; Mon, 5 Mar 2018 16:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFj-d7vHYKaN for <ila@ietfa.amsl.com>; Mon, 5 Mar 2018 16:42:13 -0800 (PST)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8A212EA54 for <ila@ietf.org>; Mon, 5 Mar 2018 16:42:13 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id k9so19158987wre.9 for <ila@ietf.org>; Mon, 05 Mar 2018 16:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/nsc35GI3keAZfHdyMWli5HPgZNigrj8D5H4Q40bySs=; b=xRoRv5QhbwB2SZDnSICGJ43A+017NSnQ/M9DPpZvfOBBxrLLqX3OxD49UBgCa8sZ2N Cu3yOW0oEJJDt1jx2ewwsaNtOVSnxGrCflSAVFwucbLR9tD1PpY65/eODPkA1vnBUamE qKj5PAS/xca2BP/Ztd7ZgMIZ0uIEWRvw28bLBXAvDf03B7B69/heM0jYo22MwhcHcXvS Rwfu0VGz7arwW3pvadnnJKttlJufTCufvs7eJI+RTDS2Xy3+okRYUktelOtD+0b9anU+ K/6h2Ir8qy02DhwM7Ryu+fwh8D2puxk5j1yq88abwr5WVMWcARkZMtlU7CyUj7/A+GZD obyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/nsc35GI3keAZfHdyMWli5HPgZNigrj8D5H4Q40bySs=; b=gocgGHVY8EkaNiBFzPKfClrTGgOmpmslRr0Mi43BPuEg5owDM67DVcSai+gShc6Kpn ZkanFu8CGPgTCR9Noy+rduIhuihIYrXeagmqOe9+XglqCw7z3B/SGbBpjJGds21SRy5H s1MlmLvAF2ZSFw+qLb55RUhhtOU2FArdit6As0pilWGJExd0+haf+FSXfwHnDmForIxu nV1I6kAGV6g02mnkfmWIgEGfuqyvpB9Uu/3F+N6HBUjE4s82yflH4c2zrwmXZ0ykqDUg Aa7sjMwtvh0pzDTvDaK+O73eRyehkbqrmSiYzSJSSflvEIwL3xj8F2JgH9f5LACxKQ0Q cFCg==
X-Gm-Message-State: APf1xPBSpz0WCGyzJdf+uSrcu564Uzil1K6b+Oay6aQDyIQFNZ93s5M/ k5JljYxCHqnSrcy3iwicQel42zNK68kf3dZIFxeQSQ==
X-Google-Smtp-Source: AG47ELtNSX4fanodyXhWrW3QpZoxF3NfnLhCB7o9W2raB47dx8tnMyeI6NWlC93wL8+6kqfeT7VyapYpddFFMJ0lOjE=
X-Received: by 10.223.191.10 with SMTP id p10mr15084568wrh.160.1520296931856; Mon, 05 Mar 2018 16:42:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Mon, 5 Mar 2018 16:42:11 -0800 (PST)
In-Reply-To: <F1093230-C087-4168-9C5F-8DA7AB677677@cisco.com>
References: <F1093230-C087-4168-9C5F-8DA7AB677677@cisco.com>
From: Tom Herbert <tom@quantonium.net>
Date: Mon, 05 Mar 2018 16:42:11 -0800
Message-ID: <CAPDqMer58nxEixtH=JuZh9WgM0xKkEQYEjwZ6zg3wTjD76gOHQ@mail.gmail.com>
To: "Alberto Rodriguez Natal (natal)" <natal@cisco.com>
Cc: "ila@ietf.org" <ila@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/rCXC3dit4IEzwIlk8755YyA7-4A>
Subject: Re: [Ila] LISP for ILA
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 00:42:18 -0000

Thanks for posting the draft!

Overall, I think the approach straightforward, and it's very nice that
there is no change required to the ILA architecture.

I have some concerns about the LISP control plane in terms of
DOSability and scalability. Btw, LISP is not in Linux kernel because
of concerns about DOSability, so there was some prior discussion on
this topic in related mailing lists,

>From the draft: "When an ILA-N has to send traffic towards a remote
Identifier for which it does not have the associated Locator, it has
to obtain it first from a MS."

This is not actually true. The forwarding cache in the ILA-N is a
routing optimization, if there is no entry on the cache then the
packet is forwarded. If it needs to be transformed then that will be
done by an ILA-R in the path. Until the cache is populated the routing
might be sub-optimal but packets still flow.

This is reflected below in: "While the mapping is being resolved via
the Map-Request/  Map-Reply process, the ILA-N can send the data
packets to the underlay using the SIR address."

I think it should be assumed in ILA that not queuing packets and not
dropping packets because of resolution are requirements (too much
latency hit).

If the map request is sent and the packet is forwarded, that means
that a packet received at the ILA-N can generate two packets to be
forwarded in the network. An obvious DOS attack is for a host to send
random to destinations in the network to try to generate cache misses.
Section 8.2 discusses this, but the solution to implement heavy
hitters counters is not detailed. It would be nice to see more detail
how this would work and how it will mitigate the DOS attack.

In ILAMP, a redirect method is defined. On a chache miss the packet is
forwarded and no other action is taken. If an ILA-R does
transformation it may send back a mapping redirect informing the ILA-N
of a transformation. The redirects must be completely secure (one
reason I'm partial to TCP) and are only sent to inform an ILA-N about
a positive response. To a large extent this neutralizes the above
random address DOS attack. There are other means of attack on the
cache, but the exposure is narrowed I believe.

"LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP
transport, however the exact same signaling can be used over a TCP
transport without affecting the protocol operation."

What is the status of TCP support? I believe the trend in datacenter
control protocols is towards TCP and even RPC. Integrated security,
congestion control, authentication, and tooling are strong points in
favor of TCP. Is it reasonable to say that TCP is the preferred
protocol? Can the LISP message easily be converted to RPC (REST,
Thrift, GRPC, ...?

Looking at the map-reply message format, I am concerned about its
size. By my count, it's 40 bytes to provide one record with one
locator where record and locator are 8 bytes. If we need to scale a
system to billions of nodes this overhead could be an issue even if
it's the control plane. Is there any plan to have a compressed version
of this. For instance ,if there is only one RLOC returned wouldn't the
priorities and weights be useless?

Thanks,
Tom


On Sat, Mar 3, 2018 at 10:39 PM, Alberto Rodriguez Natal (natal)
<natal@cisco.com> wrote:
> Hi all,
>
>
>
> We have just posted a draft describing how to use the LISP control-plane
> with the ILA data-plane. The document is in an early stage and any feedback
> is welcome. We hope to be presenting this at London.
>
>
>
> https://tools.ietf.org/html/draft-rodrigueznatal-ila-lisp-00
>
>
>
> Thanks,
>
> Alberto
>
>
> _______________________________________________
> ila mailing list
> ila@ietf.org
> https://www.ietf.org/mailman/listinfo/ila
>