Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]
Tom Herbert <tom@herbertland.com> Wed, 09 May 2018 15:21 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969DE12D93E for <5gangip@ietfa.amsl.com>; Wed, 9 May 2018 08:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 OIpdrLp9AwCq for <5gangip@ietfa.amsl.com>; Wed, 9 May 2018 08:21:05 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 CDEAE1242F5 for <5gangip@ietf.org>; Wed, 9 May 2018 08:21:04 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id d3-v6so46072449qtp.11 for <5gangip@ietf.org>; Wed, 09 May 2018 08:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pa3XxOefBqe1VzdcFMOd2Y0bOg0rCAiQXjAHVF/CfMs=; b=xtQJyFdrqrSv4wsXcsb04B6yBuoH0IJsy2vUD3XQtOqwJwf6PRV7QAt3TlpmvhIpIv +3oLiaIiyfb/sKOQ1rQTR4VYD4H2OneiuPiadVexYwub/tzBpC34pKBlN0HYnZ7xACkg LrNEl/dzkOmg6cFdcQ5xX87DNzzLOxfDZjKqZcE9AUV0F2C0SOl7ARqEhl3uvAgvjKIp ThsT/8yS+I9U98/4qlE51EX06Gcdr0N/WjeMiajyPb6vgeQSjFgYlbDGtb92WK/GKn5J c3QyMtZ6GfIUgJpCbaDAQd0xZxSKQNuzwekqgwzkKGUZMIYNK20EZKwLvMVUmoTT4UfK 90Lw==
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:content-transfer-encoding; bh=Pa3XxOefBqe1VzdcFMOd2Y0bOg0rCAiQXjAHVF/CfMs=; b=mz17gom3g2CGaKXfMZmwTtg2JI54FgI8atyQpvfd21o2ufD7mK1PQdxTojP6FYQfgZ G1A/80wccxEcldadHGkrLDw0u4p8LaY8Sd/Cg+OHISgUbV1fMPL8TRTYuMYZyxuXHDJ9 8vIOJE6WTKvY7V1GLKuqSRJ8RobAAiDJSvkldWT/V11QxA8YRZKzZrsbrNOF1k4N7FP9 oqEgtW04Gn6Z6jABsr0tQW4vQvPgXLjpqPFOXqatk4KtA6aYLjFItd7E+IOPvuNB0O6q mY4SytxRyx5Hze9f/BUrOi4rJKMkd56q0eEVPeRg4NyFnwVgqAR/1rUvYtgyb9I9GQyB GxTw==
X-Gm-Message-State: ALQs6tC9l7C6cACm8yQWoSSY0AQ9mrLPmBsl5EycRlrsw0ktoK+IGXH6 p6OFCZgs+Xf2yr9xGeNvFraTgBeb8AXOsXjOv3QNbQ==
X-Google-Smtp-Source: AB8JxZonOXH/mMLI4zk08e1PCm6TjFYeHzf/bs6Xe2ldbQh7xblYg/t3bkkSuAGQK+BbCPcU/5KXO637sjarGMrvfJg=
X-Received: by 2002:ac8:321a:: with SMTP id x26-v6mr41740760qta.130.1525879263359; Wed, 09 May 2018 08:21:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.66 with HTTP; Wed, 9 May 2018 08:21:02 -0700 (PDT)
In-Reply-To: <CALx6S36vaexbLM64e7JOs7X_Es6UzHq2WRV9YyNz1D3+cb98nQ@mail.gmail.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> <CAKD1Yr08UuXMNnCfng_Byb3ZLCCCT5Vn8YAM0a4gcekafavTew@mail.gmail.com> <CAPDqMer1bkEPVbHozmooXdm5r6Pkwpwp00TAesMWeU4nUF6p6g@mail.gmail.com> <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.com> <CALx6S36vaexbLM64e7JOs7X_Es6UzHq2WRV9YyNz1D3+cb98nQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 09 May 2018 08:21:02 -0700
Message-ID: <CALx6S36_NSO624PPxyAq_DeSMqL7Qd8WBHNuauOi_ygzqcqwFA@mail.gmail.com>
To: "FIGURELLE, TERRY F" <tf2934@att.com>
Cc: Tom Herbert <tom@quantonium.net>, Lorenzo Colitti <lorenzo@google.com>, "Joel M. Halpern" <jmh@joelhalpern.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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/aGsA1hwBtI8hsrZ9TmOi6EqNBGw>
Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 15:21:11 -0000
On Wed, May 9, 2018 at 8:08 AM, Tom Herbert <tom@herbertland.com> wrote: > On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F <tf2934@att.com> wrote: >> Nope, we handle QUIC. Spent lots of time with Google on that one. Many > > Terry, > > QUIC was only an example. I'm am concerned with the next QUIC, next > real time gaming protocol, next application protocol that might > benefit from a different transport. There's no reason to believe that > QUIC and TCP constitutent the complete set of transport protocols that > we'll ever need and that those are the only ones we should be allowed > to use on the Internet. NATPT and proxies enforce their concept as to > what transport protocols are allowed. Proxies introduce the addional > complexity in that they make it harder to deploy new options and make > it impossible to use end to end transport header authentication. > > This is why protocols like ILA are explicitily independent of > transport layer. They don't require DPI, they don't require flow state > to be tracked in the network, and they don't require packets of a flow > to always hit the same devices in the network. They can however solve > problems at the network layer (the aforementioned privacy in > addressing for example). > I should also mention that blocking unsoliticted traffic and providing flow specific services are still relevant, but these can also be done in a transport independent manner. See FAST proposal (draft-herbert-fast-00). Tom > Tom > > >> people here have worked at T-Mobile USA and the flip. T-Mo USA does block >> unsolicited but this gets deep into the details of unsolicited and fine >> lines of block or do not support or enable it to happen. >> >> T-Mobile by country does have differences. They got a lot more address space >> from RIPE than T-Mo USA got from ARIN. So in the states they use NAPT. They >> do support NAT traversal but do not host TURN. If the T-Mo USA and Sprint >> deal goes through they will have some huge challenges to efficiently combine >> things. >> >> They also use the exact same SGW/PGW vendor and hardware model as we do. So >> does Verizon (Cisco ASR5500). They may still have some of the older ASR5000 >> and Verizon may too. Neither has a virtualized solution in production. We >> have both Cisco and Affirmed carrying live paying production traffic. We >> stopped adding hardware based solutions more than a year ago. We also have >> virtualized MME (Ericsson) since last year and Nokia is in certification >> testing. We have virtualize most of the IMS domain and mobility systems >> except RAN. We are working on RAN. >> >> We are using CUPS for launch of 5G this year. Still debating the options >> longer term but we also need standards to make decisions. >> >> Back to unsolicited. >> >> We all support methods so traffic flows like video chat can work but key is >> we all work directly with those ASP’s (Application service providers). All >> of us have special handling of traffic to Amazon, Apple, Google and so on. >> The difference is in the functionality, scale and number of ASP’s support >> where we smoke everyone! >> >> So you can build an App for Apple iOS or Google’s Android and it can work >> well. You can also do peer-to-peer but only as long as the setup goes thru >> servers that are enabled. In our case you could also use our API’s. Mobile >> to mobile is only allowed when enabled. >> >> While unsolicited is the common term used in the mobile industry perhaps >> unwanted or undesired gives a better view. User’s don’t want SPAM and they >> don’t want threats (risk of device being compromised). But if they download >> and setup an App they do want that to work. >> >> It also gets to the definition of Internet. In the US very little mobile >> traffic ever goes over the “Internet”. It’s all protected private networks >> between mobile operators and data centers. Even inside the data centers the >> traffic uses servers dedicated to mobile users. Within the data center it >> may go from mobile servers to non-mobile servers. >> >> We also have major hosting companies and cloud providers covered. A startup >> may rent capacity from Amazon but mobile traffic goes over a protected >> (encrypted) path on a private network to Amazon data centers worldwide. Same >> for most major hosting facilities worldwide. >> >> This is true for most mobile operators and often even when they don’t know >> it. There are some places where things are different like China. Everyone >> does what they are told to do in China or you won’t be in China. Lots of >> complicated partnerships to make anything work. So your traffic is visible >> to some parties when there is no other option. >> >> All of the big CDN solutions and CDN supplies work with this model. So >> Akamai for Verizon mobiles is different from Akamai on AT&T mobiles. In our >> case this only goes to Akamai servers in AT&T hosting facilities. So for all >> of the major mobile operators in the entire Western Hemisphere. In reality >> it’s true for all mobile operators in Western Hemisphere to any significant >> service even when they don’t know it. It doesn’t matter who is the local LEC >> or what ISP the mobile operator uses. >> >> We even protect open WiFi and I wanted to protect all mobile “Internet >> services traffic” but that is in the future. We detect if a VPN is in use or >> if one starts to stay out of the way in the current open WiFi case. We can >> split and run traffic from UE over one VPN while running tethered (mobile >> hotspot, USB, Bluetooth) traffic outside the VPN or in a different VPN. We >> even support corporate VPN so the traffic actually goes over private network >> to corporate servers instead of coming in their “Internet” connection. >> >> You may ask about ISP peering points but in those cases for partnered >> content we use encryption. A company could use Level3 as an ISP then serve >> Internet content on that connection. If we don’t have a partnership deal >> with that company then traffic would be protected to our closest to content >> peering point with Level3. >> >> Another way to say it is for the top X websites by clicks/hits, top Y sites >> by volume (bytes) or top Z sites by connection for the busiest hour, busy >> period, day of week, etc. for any operator you can draw a line. Above that >> line the traffic is secured mobile to/from content. Below the line it may be >> secured or it may not. >> >> The rules for handling the Internet in a given country can be very complex. >> In many countries you can count on one or two fingers your options as a >> mobile operator when they are not THE LEC/ISP. >> >> Sent from my iPhone >> >> On May 8, 2018, at 7:44 AM, Tom Herbert <tom@quantonium.net> wrote: >> >> >> >> On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti <lorenzo@google.com> wrote: >>> >>> FWIW, I believe there are large operators that do not block unsolicited >>> inbound traffic to mobile networks. One of them is T-Mobile. >>> >> I should hope that a majority of access networks don't do that, lest it >> would be impossible to deploy new transport protocols (like QUIC for >> instance) and the ossification of the Internet would be complete. >> >> Tom >> >>> 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 >>> >>> >>
- [5gangip] ILA forwaring [Was Re: Problem Statemen… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… Dino Farinacci
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… Tom Herbert
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… FIGURELLE, TERRY F
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… Alberto Rodriguez-Natal
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Alberto Rodriguez-Natal
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] ILA forwaring [Was Re: Problem Stat… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [5gangip] [Ila] ILA forwaring [Was Re: Proble… Behcet Sarikaya