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

[Tom Herbert <[e-mail]>]

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