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

["Joel M. Halpern" <[e-mail]>]

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.

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.

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