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

[Tom Herbert <[e-mail]>]

On Wed, May 9, 2018 at 8:08 AM, Tom Herbert <[e-mail]> wrote:
> On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F <[e-mail]> 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 <[e-mail]> wrote:
>>
>>
>>
>> On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti <[e-mail]> 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 <[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
>>>
>>>
>>