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

[Lorenzo Colitti <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> > Sent: Thursday, May 03, 2018 3:00 PM
> > To: Joel M. Halpern <[e-mail]>
> > Cc: FIGURELLE, TERRY F <[e-mail]>; [e-mail]; Tom
> > Herbert <[e-mail]>; [e-mail]; Alberto Rodriguez-Natal
> > <[e-mail]>; 5GANGIP <[e-mail]>
> > Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]
> >
> > On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <[e-mail]>
> > 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 <[e-mail]>
> > 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 <[e-mail]> On Behalf Of Tom Herbert
> > >>>> Sent: Thursday, May 03, 2018 10:46 AM
> > >>>> To: [e-mail]
> > >>>> Cc: Tom Herbert <[e-mail]>; Joel M. Halpern
> > >>>> <[e-mail]>; [e-mail]; Alberto Rodriguez-Natal
> > >>>> <[e-mail]>; 5GANGIP <[e-mail]>
> > >>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem
> > >>>> Statement]
> > >>>>
> > >>>> On Thu, May 3, 2018 at 9:23 AM,  <[e-mail]> 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:[e-mail]] On Behalf Of Tom
> > >>>>> Herbert
> > >>>>> Sent: Mittwoch, 2. Mai 2018 01:20
> > >>>>> To: Joel M. Halpern <[e-mail]>
> > >>>>> Cc: Tom Herbert <[e-mail]>; [e-mail]; Alberto
> > >>>>> Rodriguez-Natal <[e-mail]>; 5GANGIP
> > >>>>> <[e-mail]>
> > >>>>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem
> > >>>>> Statement]
> > >>>>>
> > >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern
> > >>>>> <[e-mail]>
> > >>>>
> > >>>> 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
> > >>>>>>> <[e-mail]> wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert
> > <[e-mail]>
> > >>>>
> > >>>> 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
> > >>>>>>> [e-mail]
> > >>>>>>> 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
> > >>>>> [e-mail]
> > >>>>> 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
> > >>>> [e-mail]
> > >>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>