Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]
Lorenzo Colitti <lorenzo@google.com> Tue, 08 May 2018 13:40 UTC
Return-Path: <lorenzo@google.com>
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 6B42B12E3AE for <ila@ietfa.amsl.com>; Tue, 8 May 2018 06:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1rRwH2-Gb8in for <ila@ietfa.amsl.com>; Tue, 8 May 2018 06:40:16 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 6C31D12E87D for <ila@ietf.org>; Tue, 8 May 2018 06:40:15 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id j4so18936575wme.1 for <ila@ietf.org>; Tue, 08 May 2018 06:40:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l/iCAgZ+RJQ9eSrn0HCJrpvdCNUdVT0lwol7sxzgzIw=; b=l1OHLSvjvLkSd+dyJn2AFaiAvbnLNQ1iIa4fLp5g+yGo9Aixpn3chcVvqTASxgCDQe c7lL0hoAaxh3Jo/A6m0RrqYAfXeTFq36SW3Rya9yb/afsruhdT3BObfsLdD7gWjasxUQ j2ysz8mEbR2NXOVkTaDvXK2jfP+PCg9tRdtA9sVDOs4FPRgMONGAqjbVo1YB59Lek27G Zd3MBKQ1p0nxbOf3X5BMlxD2LcsKZjt+060UV31e+yv1ZYv3eyUoNnUvYG5aegbZy/Ma HQ+/jYK9LOXcgLA2UhPbXaNgSBdaVV46a1YQfD6vhwsAZKU9xekZB9Z1U4WspfPSnhUL oryA==
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=l/iCAgZ+RJQ9eSrn0HCJrpvdCNUdVT0lwol7sxzgzIw=; b=PkjgrS4DJAbjyWJN5d6IYkayWWTygUzkplP11nVHGk9WME2earVuv9X180WwHfMhOF BpSXBKySD4ru3TomsJzvhJyP3oL1l03JIFTRopN1+hwQqg2nlwPqYq5Zmg20A4+iMUTE G2rgEDEQvVrTTjtt5tnw2pPQEa1969nWm+ST0DT0+TkIyRhtnRaoexW994WS+hg3BKY4 EKX/jIWgaN2pzWXSDVTPRU1hjRcVtDYEc1jFu+1V8MstN8jt+1+Pil1w8A9Pkb2mwGXD PaW9gwAhJ7vuEFtgOGcy7t9CnSWtsNGFgA/iCqFhvevKZCcuKeCjGmQO8qOYFJx2B4e/ wqjA==
X-Gm-Message-State: ALKqPwfSl371taJ0IfdRmh2f8VZ/WiHX3zEPDYpXOpuVdoyWnKvvzXiw mHz1dVLvORn7RC7X9lDmfaohYtD63hShJtNaMl8mfg==
X-Google-Smtp-Source: AB8JxZrj0Bb5GC+89UGe2DN4PMZdyKDuFrp1xf8MsWeUjrPUBaar0sShimieaK4PqGyw+3VP1u6RseMvUexyWCYBaME=
X-Received: by 2002:a1c:340f:: with SMTP id b15-v6mr3172747wma.129.1525786813349; Tue, 08 May 2018 06:40:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.247.25 with HTTP; Tue, 8 May 2018 06:39:52 -0700 (PDT)
In-Reply-To: <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.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> <CA+YHcKF3z+LoVE=18HMgTNTpCN+23dDjkDx8bhZzWPdTeiX-_Q@mail.gmail.com> <CAPDqMeqcy-9+_Dk0yp=j7icQkDTvYnkYiwAbvRCq3oJ7UPciQA@mail.gmail.com> <fdaafdea-7d59-2542-3bef-ae86e96782dd@joelhalpern.com> <CAPDqMeo+wgHGxn_eiH1c100W_0kN_3cFyfZMRPn5Be42d9F8Cw@mail.gmail.com> <8aee42db5f0f407c86fda881769ceb77@HE105715.emea1.cds.t-internal.com> <CAPDqMeqgrOmoTstvJXnKCvG+WogQun_WvQGRg-V3Jm6OrnbFYw@mail.gmail.com> <1AFE10CF28AE8B4C9663445736B8034D3822FAFE@CAFRFD1MSGUSRJI.ITServices.sbc.com> <CAPDqMerK9ZUWGnj7EWtvZr0bb6J+4ketpK-QxKEytonQL8FNzA@mail.gmail.com> <0cbb9987-0b47-9428-3db7-2c9fab821268@joelhalpern.com> <CAPDqMepRwxtdLpf17NLLeR72sTvXhz=3RMdtn7ru-4gC=iFjXA@mail.gmail.com> <1AFE10CF28AE8B4C9663445736B8034D3822FC27@CAFRFD1MSGUSRJI.ITServices.sbc.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 08 May 2018 22:39:52 +0900
Message-ID: <CAKD1Yr08UuXMNnCfng_Byb3ZLCCCT5Vn8YAM0a4gcekafavTew@mail.gmail.com>
To: "FIGURELLE, TERRY F" <tf2934@att.com>
Cc: Tom Herbert <tom@quantonium.net>, "Joel M. Halpern" <jmh@joelhalpern.com>, Tom Herbert <tom@herbertland.com>, "ila@ietf.org" <ila@ietf.org>, 5GANGIP <5gangip@ietf.org>, Alberto Rodriguez-Natal <rodrigueznatal@gmail.com>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>
Content-Type: multipart/alternative; boundary="00000000000003e1d1056bb1ed10"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/xHMS2sRKBuqendIm436CpaOsVEM>
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, 08 May 2018 13:40:21 -0000
FWIW, I believe there are large operators that do not block unsolicited inbound traffic to mobile networks. One of them is T-Mobile. On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F <tf2934@att.com> wrote: > No. We have always block unsolicited traffic from the Internet and it is > too complicated to discuss here. > > We even did this way back for CDPD. For dedicated APN's we allow the > enterprise to tell us what rules they want to protect the mobile from their > network and what traffic to not allow from the mobile. This is one of the > reasons firewalls and CNAT cost more if they support mobility features. We > spent a lot of time working with potential vendors. > > Since this started with usage based rate plans for all mobile operators > the subscriber would get charged if we allowed spam from the Internet or > from other mobiles. So this has always been block and vendors have features > to help out in 3GPP elements. A GGSN with anti-spoofing not disabled > doesn't allow traffic to a mobile that doesn't match an entry in the flow > table. We have hundreds of policy rules that get enabled from the PCRF/PCF > on the PGW(PCEF)/UPF. We also enabled our proxies to be transparent > proxy-TDF. That means they also have policy interfaces and we do a bunch of > stuff here including processing signed manifests. Plus the rules are pushed > on the control plane not the data plane and it includes UE, RAN, > SGW/PGW/UPF and if applicable TDF's and AS's. We can push rules to the UE > that allow, (drop), route/path (e.g. bearer). We even have to have some > country specific treatment (a bigger challenge we had for vehicles using > our Connected Car solution like GM OnStar). > > While a mobile could get hacked and it could break the flow rule treatment > some of that is down in the 3GPP chipset. But we are aware of the risk and > we have counter measures as best we can. I should point out that these flow > rules go into RAN too and rules have a direction (from UE, to UE or both). > > My opinion is that malware, spoofing, DOS, DDOS and any other threat is a > serious operational issue. That is the best place to deal with it because > standards could never keep pace. We and other operators request features > from vendors and they also come up with stuff as a value add. > > Simply stated the solution needs to be protected but we don't need tons of > detail in every standard. > > I would never say don't be concerned about something. I just don't think > every standard needs details on spoofing, DOS and other threats. > > > > -----Original Message----- > > From: Tom Herbert <tom@quantonium.net> > > Sent: Thursday, May 03, 2018 3:00 PM > > To: Joel M. Halpern <jmh@joelhalpern.com> > > Cc: FIGURELLE, TERRY F <tf2934@att.com>; Dirk.von-Hugo@telekom.de; Tom > > Herbert <tom@herbertland.com>; ila@ietf.org; Alberto Rodriguez-Natal > > <rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org> > > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement] > > > > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <jmh@joelhalpern.com> > > wrote: > > > I am missing something in your DDOS issue. > > > > > > At first, I thought the real issue (which you seem to be suggesting > > > here) was DDOS from the Internet, using spoofed or non-spoofed > > > addresses (with bot farms, there is much less need for or relevance of > > spoofing). > > > > > > But then I tried to map it to the cases we have for using ILA. > > > The primary case I have heard about is to use ILA for UE<->UE and > > > UE<->EdgeComputing traffic. If so, just filter all SIRs on incoming > > > packets from the Internet. They aren't legal there. And similarly, > > > if one uses LISP within the operator domain, we can block whatever > > > blocks we use for EIDs for such local traffic. > > > > Joel, > > > > I'm not sure I understand what "filtering SIRs from the Internet" > > means. A SIR address is a globally visible address for devices like UEs. > So an > > Internet sender may legitimately send packets to SIR addresses, and also > an > > Internet attacker could easily spew a whole bunch of packets with both > spoofed > > source addresses and spoofed UE addresses. So you'd want to allow the > > legitimate traffic but block the attacking packets-- this isn't feasible > since it's > > impossible to distinguish the bad from the good packets. > > > > > > > > If we want to use id-locator split of any kind for handling traffic to > > > / from the Internet, then we have to understand how that is supposed > > > to work, and why, before we need to evaluate DDOS implications of a > > > solution. For LISP,the working group has explicitly said that > > > Inter-wide deployment is out of scope. > > > > > > Net: I do not see in currently described deployments, an issue that > > > differentiates LISP from ILA in these regards. And Terry has very > > > clearly spelled out that for mobile operators spoofing from UEs is not > > > considered an issue that the infrastructure needs to deal wih. > > > > But there may be a whole network infrastructure of hundreds or even > > thousands of users behind a UE, and there's no guarantee that that > > infrastructure properly supports anti-spoofing. This basically this case > has the > > same problem as in the Internet case. > > > > Tom > > > > > > > > Yours, > > > Joel > > > > > > > > > On 5/3/18 5:33 PM, Tom Herbert wrote: > > >> > > >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F <tf2934@att.com> > > wrote: > > >>> > > >>> In the case of current 3GPP operators all the major vendors support > > >>> anti-spoofing. The default was on for all but one vendor which got > > >>> corrected the last time I did an RFP for EPC. So by configuration > > >>> the GGSN/PGW/PGW-U/UPF will not allow the UE to send packets that > > >>> don't match either the exact IP address or pushed subnet or prefix > > >>> delegation that was sent in response to the APN create message. > > >>> Obviously if we remove GTP encapsulation that protect MAY need to be > > enhanced towards an EDGE element. > > >>> > > >> Terry, > > >> > > >> Even so, the whole Internet does not require anti-spoofing, nor do I > > >> believe that operators could require all down stream network that are > > >> connected to support anti-spoofing. These are where the DOS attacks > > >> orginate. The problem is when caches are being driven by user taffic > > >> from these external networks, mitigations to detect DOS by IP source > > >> address don't work without anti-spoofing (but even if they had > > >> anti-spoofing that still doesn't work when under a DDOS). > > >> > > >> Tom > > >> > > >> > > >> > > >>> This is being covered as part of our participation in an open source > > >>> vEPC (virtualize EPC, hypervisor, blah, blah, blah). So there will > > >>> be a micro service firewall that can be deploy at the edge plus we > > >>> already have planned support for big network infrastructure vendors > > >>> and 3GPP supplies (Cisco, Juniper, Ericsson, Nokia, Huawei, ...) to > > >>> cover this. Since this can be a non-3GPP element we will get this > into > > ONAP. > > >>> > > >>> Thus we have this covered both for 3GPP nodes, micro services and > > >>> open source efforts. To give examples without vendor names there are > > >>> GTP aware firewalls that some operators use. It really just another > > >>> capability in carrier class and business class firewalls (had to add > > >>> it to load balancers, CNAT/NAT, some Wi-Fi routers and to our DNS > > >>> solution which uses open source). Obviously this will be supported > > >>> via a RADIUS feed for backwards compatibility. Today most GTP > > >>> firewall simply follow the GTP-C signaling to learn the IP > > >>> address(es) assigned to the UE for an APN. If we remove GTP from > > >>> user plane that doesn't mean we remove it from control plane or for > > >>> all hops. However, we will likely push to a micro service at the > > >>> cell plus I need to check if we ever ask RAN vendors to support > this. I'll add > > this for 5G but we already did that RFP so it's a change order (yuck). > > >>> > > >>> I am not good at wordsmithing but I suggest there be some paragraph > > >>> that covers network elements that can except a RADIUS feed. I need > > >>> to talk to our standards team to see if we want this on T8 > (probably). > > >>> > > >>> So today for all AT&T, Verizon, Vodaphone, ..... I know or am > > >>> fairly confident they have anti spoofing tuned on in the > > >>> GGSN/PGW/UPF plus I know they can turn this on per APN. Not sure why > > >>> anyone would disable this since we if you are delegating a subnet to > > >>> a Wi-Fi hotspot (instead of the typical private addressing they use). > > >>> > > >>> We actually don't need any 3GPP changes since this is already > > >>> covered using RADIUS to pass the information where it needs to go. I > > >>> suspect most will leverage their caching SPR/UDR which already has > > >>> the information. Even the GGSN we launched EDGE/GPRS when I was much > > >>> younger supported anti-spoofing and many vendors cover this via a > > >>> number of methods (e.g. COPS works for older junos and RADIUS for > Cisco > > IOS releases ). > > >>> > > >>> My suggestion is that I am willing to help whoever wants to craft > > >>> the paragraph because I suck at that (fortunately I am good at other > > things). > > >>> > > >>> I don't think we need any changes to any standards to cover this > > >>> since we already cover this and already are covering this if we > > >>> strip out GTP (at least for one leg). I'll make sure it gets into > > >>> our RAN requirements if not there since that may be the best place > > >>> for that edge. Plus I'll get it covered thru the ONAP open source > > >>> effort we drove (we donated the software to the open source effort). > > >>> That means FM, PM, CM and IM will be covered in some future ONAP > > release (takes time but faster than 3GPP). > > >>> > > >>> It's a bit debatable what is RAN when using virtualized network > > >>> functions > > >>> (VNF) and a bunch of open source stuff that we put it into all of > > >>> the needed elements like SDN, firewall, load balancer (not sure > > >>> that's needed at cell site but it is for core DNS, proxy-TDF and > > >>> CNAT) out at the cell site. We aren't there yet (still physical > > >>> eNB/NR and obviously we need hardware assist even with > > >>> virtualization plus tight control of timing). I am looking forward > to when we > > start using containers. > > >>> > > >>> For our core I am sure we will use our UDR VNF as the cache for > > >>> whatever comes out of this effort in final standards. The > > >>> information is already there (IMEI, device vendor, subscription > > >>> information, UE IP address, APN, etc.). If we do anything it would > > >>> be to augment an open source and if needed a 3GPP. I don't think we > need > > any changes but it's always best to verify. > > >>> For current RAN an anti-spoofing feature would come from EMS which > > >>> can be via ONAP. I don't think that is a standards effort thing > > >>> since it's a feature which may or may not already be covered but it > > >>> will be in future RAN releases probably starting with eNB/NR with > > >>> some vendor release if it's not already a feature. I want to say > > >>> Ericsson and Nokia already can do this in eNB but I need to go thru > > channels to ask. > > >>> > > >>> So maybe that paragraph recommends implementing anti-spoofing at all > > >>> edges and leaves it at that. Or we could say all edges including RAN > > >>> if that makes people happy. > > >>> > > >>>> -----Original Message----- > > >>>> From: 5gangip <5gangip-bounces@ietf.org> On Behalf Of Tom Herbert > > >>>> Sent: Thursday, May 03, 2018 10:46 AM > > >>>> To: Dirk.von-Hugo@telekom.de > > >>>> Cc: Tom Herbert <tom@herbertland.com>; Joel M. Halpern > > >>>> <jmh@joelhalpern.com>; ila@ietf.org; Alberto Rodriguez-Natal > > >>>> <rodrigueznatal@gmail.com>; 5GANGIP <5gangip@ietf.org> > > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > > >>>> Statement] > > >>>> > > >>>> On Thu, May 3, 2018 at 9:23 AM, <Dirk.von-Hugo@telekom.de> wrote: > > >>>>> > > >>>>> Hi Tom, > > >>>>> I understand you correctly that DDOS attacks can never be > > >>>>> completely > > >>>> > > >>>> prevented whatever protocol you use. > > >>>>> > > >>>>> It will however always remain related to known IP addresses and > > >>>>> the more > > >>>> > > >>>> versatile these are handled a mitigation strategy could be designed. > > >>>> > > >>>> Dirk, > > >>>> > > >>>> I disagree. IP addresses can too easily be spoofed, it's easy to > > >>>> hide identity behind a NAT (see discussion about CGNAT and law > > >>>> enforcement on int-area list), and trying to turn off individual > > >>>> addresses doesn't work if it's a DDOS. This is nothing new. For > > >>>> instance, content providers have long accepted the fact that they > > >>>> can't prevent SYN attacks and there's little point to trying to go > > >>>> back to source IP address (they are always spoofed in a SYN > > >>>> attack). The better strategy is to absorb the attack and minimize > > >>>> the negative effects so that the attack is not worth the effort. > > >>>> > > >>>>> As you may have seen we mention improved handling of mapping > > >>>>> systems > > >>>> > > >>>> and subsequently of DDOS protection also in the current version of > > >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=https- > > >>>> 3A__github.com_bsarikaya_atic_blob_master_atick- > > >>>> 5Fproblemstatement.3.txt&d=DwICAg&c=LFYZ- > > >>>> > > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 > > >>>> OstVOL1OQiA98fgBJ9c1Gjo&s=jLL_9a56R8Ic8o3uJcR8mrF- > > >>>> JkzLL97h8rmZT_EqXnQ&e= which Behcet has announced recently. > > >>>>> > > >>>>> May I ask you to please comment on the ideas outlined there? > > >>>> > > >>>> > > >>>> I don't see much difference in the latest version. For a problem > > >>>> statement, I still think there is too much focus on the solutions > > >>>> and not nearly enough description of what the actual problems are > > >>>> to be solved. > > >>>> > > >>>> Tom > > >>>> > > >>>>> Thanks! > > >>>> > > >>>> > > >>>>> Best Regards > > >>>>> Dirk > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: 5gangip [mailto:5gangip-bounces@ietf.org] On Behalf Of Tom > > >>>>> Herbert > > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20 > > >>>>> To: Joel M. Halpern <jmh@joelhalpern.com> > > >>>>> Cc: Tom Herbert <tom@herbertland.com>; ila@ietf.org; Alberto > > >>>>> Rodriguez-Natal <rodrigueznatal@gmail.com>; 5GANGIP > > >>>>> <5gangip@ietf.org> > > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem > > >>>>> Statement] > > >>>>> > > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern > > >>>>> <jmh@joelhalpern.com> > > >>>> > > >>>> wrote: > > >>>>>> > > >>>>>> You seem to be saying that even though not all DDOS attacks are > > >>>>>> structurally the same, and even though if ILA were widely adopted > > >>>>>> not all ILA networks would be structurally the same, there should > > >>>>>> nonetheless be one required qay of handling DDOS? > > >>>>> > > >>>>> > > >>>>> Yes, at least as core default in the protocol. It's precisely > > >>>>> _because_ not all > > >>>> > > >>>> DDOS attacks are structurally the same. An attacker is not going to > > >>>> conform to to our expectations of what they should be doing, so if > > >>>> we enable LISP option N to mitigate one form of attack, they will > > >>>> just use another attack that isn't mitigated. For example, if the > > >>>> mitigation is to identify attackers by address when requests from > > >>>> the address exceed a threshold then this works as long as the > > >>>> attacker strikes from one machine, but it falls apart if the > > >>>> attacker launches a DDOS attack from several hosts where requests > > >>>> from none of the hosts exceed the threshold. > > >>>>> > > >>>>> > > >>>>> The ILA model works because it assumes there is no absolute way to > > >>>>> prevent > > >>>> > > >>>> the the worst case attack on a cache which is to completely kill it > > >>>> (i.e. drive it to 0% hit rate). In this state the behavior > > >>>> sub-optimal routing, which is much better than loss of service. > > >>>> This is not dependent on the structure of the attack, network > > >>>> topology, or the network operator getting the configuration just > > >>>> right-- > > >>>> it is inherent in the protocol. > > >>>>> > > >>>>> > > >>>>> Tom > > >>>>> > > >>>>>> > > >>>>>> Yours, > > >>>>>> Joel > > >>>>>> > > >>>>>> > > >>>>>> On 5/1/18 6:32 PM, Tom Herbert wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal > > >>>>>>> <rodrigueznatal@gmail.com> wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert > > <tom@herbertland.com> > > >>>> > > >>>> wrote: > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> 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). > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> This can be misleading. This is not comparing LISP vs ILA, this > is > > >>>>>>>> comparing the models of Request/Reply at the edge vs > Notifications > > >>>>>>>> (aka Redirects) at the core. Both LISP-CP and ILAMP support > these > > >>>>>>>> two models. > > >>>>>>>> > > >>>>>>>> Besides, this is assuming an scenario where the only feasible > DOS > > >>>>>>>> mitigation is absorbing the attack. There are other scenarios > where > > >>>>>>>> other countermeasures are possible. For instance, if you have a > > >>>>>>>> deployment where you can prevent address spoofing, counting and > > >>>>>>>> blocking misbehaving nodes offers similar DOS protection and > > >>>>>>>> requires way less infrastructure resources. > > >>>>>>>> > > >>>>>>> Alberto, > > >>>>>>> > > >>>>>>> The answer to my question of how does LISP address DOS attacks > > seems > > >>>>>>> to be "there are many options". Some of the options are to assume > > >>>>>>> that DOS does not exist in the network, some assume external > > >>>>>>> configuration like address spoofing is enabled, some assume that > > >>>>>>> attacks can be identified and can be stopped at the source, some > > >>>>>>> might assume that everything is okay because there's never been a > > >>>>>>> DOS attack before. I have yet to see the effects of any of these > > >>>>>>> quantified, and none of these state how the LISP _protocol_ > itself > > >>>>>>> addresses DOS. It may seem counter-intuitive, but offering a > bunch > > >>>>>>> of options really is not necessarily a good thing-- sometime > less is > > >>>>>>> more. To put this another way LISP has been rejected from Linux > > >>>>>>> precisely because of its susceptibility to DOS. If you were to > try > > >>>>>>> again and the best answer to the DOS question is that it's up to > the > > >>>>>>> operator to figure out the right options to use, then I believe > it > > >>>>>>> would be soundly rejected again. That approach does not work at > > >>>>>>> scale. > > >>>>>>> > > >>>>>>> Tom > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> ila mailing list > > >>>>>>> ila@ietf.org > > >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_ma > > >>>>>>> ilman_listinfo_ila&d=DwICAg&c=LFYZ- > > >>>> > > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl > > >>>>>>> > > >>>>>>> > > >>>> > > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=BO3snt8C > > >>>> RQ > > >>>>>>> > > >>>>>>> gy1xwhx2CY10VUbM_rgntgpV9k3-Cskd8&e= > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 5gangip mailing list > > >>>>> 5gangip@ietf.org > > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mail > > >>>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ- > > >>>> > > >>>> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl > > >>>>> > > >>>>> > > >>>> > > 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire > > >>>> MiKC > > >>>>> > > >>>>> SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e= > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> 5gangip mailing list > > >>>> 5gangip@ietf.org > > >>>> https://urldefense.proofpoint.com/v2/url?u=https- > > >>>> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ- > > >>>> > > o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4 > > >>>> > > OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMireMiKCSkPaOGFCybzDc2i2y49Cgtbl6mC > > >>>> Lc9c&e= > > >> > > >> > > > > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip >
- [Ila] ILA forwaring [Was Re: [5gangip] Problem St… Tom Herbert
- Re: [Ila] ILA forwaring [Was Re: [5gangip] Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] ILA forwaring [Was Re: [5gangip] Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Alberto Rodriguez-Natal
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Alberto Rodriguez-Natal
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert