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

Tom Herbert <tom@herbertland.com> Wed, 09 May 2018 15:08 UTC

Return-Path: <tom@herbertland.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 854641242F5 for <ila@ietfa.amsl.com>; Wed, 9 May 2018 08:08:21 -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 Ao5ZEh2NVXmK for <ila@ietfa.amsl.com>; Wed, 9 May 2018 08:08:17 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 3914D127444 for <ila@ietf.org>; Wed, 9 May 2018 08:08:17 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id f13-v6so36275174qtp.10 for <ila@ietf.org>; Wed, 09 May 2018 08:08:17 -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=+LRO1r2PFkg7O+Pnn4YNJs+AFybMZArmVa6QJaoDJko=; b=xIVntTh17oE9m4yL9TeYcdQdX3nVwUF4j+Aoj8wdxpCt1DBegvhCCYNdA8Nc5NdTa7 TQBZNdwCz56xMeZieEhbay/hBekLqqwslMXwfh2pLF8SHYD8MNS8OquPDeJP8R14BgjE o44HvaFwu0ugkx1AOLQRlaj1Ty+rqYkKCDbwqLnmIErVn4YJkrC3XWLSiYJB9bANPX8H xkCLRsWLiIRdGdbsZbaHsM3nE4hgV3xWVbrpxd91i+PgMg5Aclqk/XZccXzgX42EIoGQ L8R08IZUFIse3FgiLmDvcQ9mkOWlrn4vqu0I5PMOAl0N5tw71YaW3Wu5qgcovSLqEWNU 0i1A==
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=+LRO1r2PFkg7O+Pnn4YNJs+AFybMZArmVa6QJaoDJko=; b=gYmRm51v2WwrUo5hs3R7HLgMQUwQAQ+FrJOhk8ROUJC8EPqB3QTmXgb9C4QasbOuy8 9+KlKpfWxBu1U+ZAgoxYeOANeXaQ4QHOy4eTpmPnMmyeqz8LkWoh20bkiyF6B3a4Oujg fp6XNcESUwqIGluBkjsaxXIzJKIWeuIGZ6dUCbJo6qD9uTpruPlzkDcH37gOHzQ6gMJe 6VfhUutFQijjKjskHP7I+DPAy2zsisKm5J7TKBgNgjvYFHmyTeWdwovZnt4UJMk9mRKn htYD200WEWxbD8Bcritc3y7/TZzA+r7m+kXyqq4SqGYq4pgH+hPLdQ1JuQavXbEOnQVe 0jKw==
X-Gm-Message-State: ALQs6tAKVC5J3fCAHRK+uuqZt48iRFoUNXJHYRXzs7kQv5O0ZBCrVTNv RvyfLOepL50oYmzoEGy2WVLpMl+d2awcYc9WjCeCOw==
X-Google-Smtp-Source: AB8JxZoxna1CxDkxtSsTJ2it7rZZDUKKT7GyRxQWLr0qzXemhleCPHMiGraOCaQ+w4VprvLPuQ6ebq5XucGAOOu2otM=
X-Received: by 2002:ac8:321a:: with SMTP id x26-v6mr41683423qta.130.1525878495638; Wed, 09 May 2018 08:08:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.66 with HTTP; Wed, 9 May 2018 08:08:15 -0700 (PDT)
In-Reply-To: <55875A79-0D4A-48EF-BCA9-A7462EBE3A38@att.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>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 09 May 2018 08:08:15 -0700
Message-ID: <CALx6S36vaexbLM64e7JOs7X_Es6UzHq2WRV9YyNz1D3+cb98nQ@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/ila/-OuSCTMtVmhAbf4l_0dE6fFI-dE>
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: Wed, 09 May 2018 15:08:22 -0000

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).

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
>>
>>
>