Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]

Tom Herbert <tom@quantonium.net> Tue, 01 May 2018 17:33 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 080F512E8CE for <ila@ietfa.amsl.com>; Tue, 1 May 2018 10:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 AC112Be6k_mc for <ila@ietfa.amsl.com>; Tue, 1 May 2018 10:33:39 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 51DEA12E8D6 for <ila@ietf.org>; Tue, 1 May 2018 10:33:32 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id v5-v6so11416228wrf.9 for <ila@ietf.org>; Tue, 01 May 2018 10:33:32 -0700 (PDT)
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=HrAlUKKuY1d0wEk+nPxoZe2Q03+rymbSQiAGL5hDwyM=; b=b4DnkjhBmrDvEvIyUabWZd0xc0PqoXsdfEfcMSpS9WIgAZGidBbZu4/Vc1k4HFOSOg NdBVWtcw6HJtBpse0DFesbZMAn7SlvVDajW9x+mBOoNnPKUAFgh42spIbsKoSz5Gbo2C 1zWsSZGl3fwqicynOzXjnpAQ+GVShu+N9gDFk2sISusBPZ/mU+tDMAucNXUyLxbQPw7B t2jdQBbccqNjTb5VLdBPWAut5/81t3k/eD1SGaED5LHHO9GB8DelRPq354qZYStC3OzA kRJO8xan2rzuKQMbSh5FCdbXO4AsVxUhlNyH+Z2eLQrmokHpm+J1RhxCVxSWAiNm7RNG 0K3w==
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=HrAlUKKuY1d0wEk+nPxoZe2Q03+rymbSQiAGL5hDwyM=; b=Cy091qwMifQrfUVXbMyCYuSPCDzcWsjZWQZ7qrYKYa1akI/tDQ20WZbsmP3p9MMI+r jaDv3Ww7RgIHE2IYUnAzLG/TuQg+/9Q2SrdgGYfpHwVNkGt7YQQo7KOmegXlY9AZ2q4M J+DQlD0CIsY+aaa9EKw/deKxedDzCGVM64SVgcDQ98mt5d03aTFHSX8XvzNIFiOXiyZH Yb+zmlebI/tcCBDSoF9BnqHSToRvksdiDuwVuNRSMxHPpOEZGmbSKrdXC0q36T+OJlFr csXPQyk/YZzMNPK/+3N7tZ1WVetJBoS3p5pydlDbAJjHGNcyOtjZY8ToP7iJV9WhWAWa ubVw==
X-Gm-Message-State: ALQs6tABwAiBEGnDHYATfLjP3fFcte6/bNOniyrcDKV7zLeZSBznqGMU 0Bw5lHM46CqxANQ4cY3Q80iJbJQ09viFqa+xR5K1rA==
X-Google-Smtp-Source: AB8JxZp7KYsvMc/1/wWoW4mEG4NMW9US3PoU38wIvRJ6dlAG4dFYKR5jwGl3nC+RTlfctPIyaeVgtwvnVoQ1AYZ4dgA=
X-Received: by 2002:adf:9162:: with SMTP id j89-v6mr12203543wrj.196.1525196010677; Tue, 01 May 2018 10:33:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 10:33:30 -0700 (PDT)
In-Reply-To: <6d25230b-aafe-e985-7e0f-f8bd3acfb800@joelhalpern.com>
References: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com> <253963a3-9e0b-2cb9-e216-745c6b99766c@joelhalpern.com> <CAPDqMeqsdG5FKtMaq9bjcJYDMw69Ow=OkeqMdba8aqRh9ayPrQ@mail.gmail.com> <08110014-adce-3f88-02d1-643871e46dcb@joelhalpern.com> <CALx6S34=Yeu3-hHTiVCOoQUM7KwvXPpGMmu8Ss-ZHeuOU6b7ug@mail.gmail.com> <6d25230b-aafe-e985-7e0f-f8bd3acfb800@joelhalpern.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 01 May 2018 10:33:30 -0700
Message-ID: <CAPDqMepbn+nDyH=EnHx_FpZOUiqkNqJMJzKGwTeJY0AhnK0Hxw@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Tom Herbert <tom@herbertland.com>, ila@ietf.org, 5GANGIP <5gangip@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/pX_swimGvKbcDwbYJ9PtRJRlxP0>
Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]
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, 01 May 2018 17:33:42 -0000

On Tue, May 1, 2018 at 10:22 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> I am not sure I follow.
> If I am reading you right, you suggest that dropping cache usage during a
> DOS attack is a useful feature.

No, that's not what I am saying. The DOS attack is on the cache in an
attempt to make every packet, including legitimate ones, take a cache
miss. This can be done by downstream devices flooding the cache node
where each packet contains a randomized address in the identifier
locator domain. In the case of ILA the packets are forwarded on the
cache miss and will be dropped if they are being sent to bogus
addresses (no route at ILA-R) packets that have routes are forwarded
as normal.

> If the system is engineered to operate well using local caches in the ILA,
> then dropping cache usage would seem to result in a DOS attack on the ILA-R
> infrastructure as it will have to handle a sustained packet load much higher
> than its design target.
>
Yes, the network needs to be properly provisioned (although these are
basically routers that would have to be in the path anyway). As I
said, if you're assuming that caches will always have some hit rate
that is the opening for a DOS attack.

Tom

> Yours,
> Joel
>
>
> On 5/1/18 1:16 PM, Tom Herbert wrote:
>>
>> On Tue, May 1, 2018 at 9:58 AM, Joel M. Halpern <jmh@joelhalpern.com>
>> wrote:
>>>
>>> If you do not use caches in your ILA-Ns (and yes, I understand your
>>> reasoning for not doing so), then you are constructing an overlay
>>> network.
>>> One of the arguments I was given for using ILA was to enable direct
>>> forwarding of packets effectively without needing to have routing track
>>> the
>>> moving entities.  Without caches, you are pushing all the traffic through
>>> fewer entities.  And you seem to be either using a lot of ILA-R with
>>> concomitant information distribution or few ILA-R restricting the
>>> information distribution problem but instead having traffic concentration
>>> problems.
>>>
>>> I understood from your earlier presentation that the ILA-r using the
>>> packet
>>> as a signal was to avoid dropping the first packet, and as a side-effect
>>> not
>>> needing a separate query message.
>>> Now you seem to be saying that your think it important to support not
>>> having
>>> caches in the ILA-Ns, which is a VERY different trade-off.
>>>
>> Joel,
>>
>> I think you've misunderstood my position. Caches are _very_ important
>> to eliminate the cost triangular routing (latency, average path load).
>> This reduces latency and reduces average load on ILA-Rs. But, and this
>> is the critical part, caches are only an _optimization_ in ILA. That
>> means if the cache is rendered ineffective (like by a well crafted DOS
>> attack) then the only effect is that the optimization is loss (i.e.
>> greater latency due to triangular router)-- this is quantitively the
>> worst effect of the attack on an ILA cache. This can be contrasted
>> that to LISP where the worst case effects of a DOS attack on the cache
>> is loss of service for users (infinite latency since packets can be
>> dropped or indefinitely blocked on a cache miss).
>>
>> Tom
>>
>>> Yours,
>>> Joel
>>>
>>>
>>> On 5/1/18 12:37 PM, Tom Herbert wrote:
>>>>
>>>>
>>>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern <jmh@joelhalpern.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Three reactions, all personal opinion (in case someone thinks my having
>>>>> helped chair the BoF is in any way relevant; it isn't):
>>>>>
>>>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in
>>>>> the
>>>>> network.  Yes, you have provision for multiple of them sharing load.
>>>>> However, if that sharing gets to be a significant percentage of teh
>>>>> routers
>>>>> in the network, then there is no point in having bothered with ILA, you
>>>>> are
>>>>> just routing on the SIR.
>>>>>
>>>> Joel,
>>>>
>>>> If you provision a network (or any system really) based on an
>>>> assumption that caches will always attain some hit rate this is a
>>>> fundamental mistake. One of the goals of a DOS attack would be to
>>>> drive the hit rate to zero in which case someone will be in a world of
>>>> hurt. Caches and DOS are a hard mix to contend with in nearly any
>>>> context, that's why it's much better to view caches as an optimization
>>>> rather than a requirement. They can be used to alleviate load, but
>>>> that cannot be relied upon.
>>>>
>>>> I would also point out that caches only make sense as internal devices
>>>> for intra domain communications. This does not make sense for edge
>>>> routers that would need to create a working set cache for any
>>>> aribtrary load of traffic from the Internet.
>>>>
>>>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no
>>>>> way
>>>>> of knowing whether the ILA-N have caches or not.  I can understand what
>>>>> happens if all ILA-N in a network have the same cache state (either
>>>>> they
>>>>> all
>>>>> have caches or they all do not have caches).  But I do not know what
>>>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the
>>>>> hot-spot issue above, I think you need to really explain why ILA-N
>>>>> would
>>>>> not
>>>>> ahve caches.
>>>>>
>>>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include
>>>> capabilities description.
>>>>
>>>>> 3 - Minor) Your usage of "sharding" seems odd.  You are simply dividing
>>>>> the
>>>>> domain into address blocks, and distributing responsibility for those
>>>>> blocks
>>>>> separately.  In other contexts, sharding seems to be used more
>>>>> generally
>>>>> for
>>>>> having subcollections of the data which can be moved around.
>>>>>
>>>> Sharding is a database term that describes partitioning of the
>>>> database into smaller chunks for manageablibilty. That is what is
>>>> happening here (literally in the implementation since we are use a
>>>> database backend).
>>>>
>>>> Tom
>>>>
>>>
>