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

[<[e-mail]>]

Hi Tom,
thanks for your encouraging words!
I agree that CGNAT should be included in the PS document to point out existing attempts for privacy.
We think of identifying requirements and open issues for all Id-Loc split approaches in an overarching way reflecting also on measures already addressed individually.
Hope you can correct us here again if we miss sth.
Thanks again!
Best Regards
Dirk 

-----Original Message-----
From: Tom Herbert [mailto:[e-mail]] 
Sent: Freitag, 4. Mai 2018 19:17
To: von Hugo, Dirk <[e-mail]>
Cc: Tom Herbert <[e-mail]>; Behcet Sarikaya <[e-mail]>; 5GANGIP <[e-mail]>
Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]

On Fri, May 4, 2018 at 8:33 AM,  <[e-mail]> wrote:
> Hi Tom,
> Thanks!
> So did I get you right? The Id-Loc split approach can help to reduce straight-forward tunneling issues which are partly also privacy and security related (you talk about that also in draft-herbert-ipv6-prefix-address-privacy-00) such as address-associated location revealing and single anchor points for attackers' attraction, but on the other hand Id-Loc approaches may create new issues due to need of accessible mapping systems (potential single point of failure, attack, and data disclosure).

Sounds about right. I tend to think that the privacy problem at IP layer is mostly about what can be inferred by a from the IP addresses in packets by a third party observer. For that point of view, it turns out that CGNAT can go a long way to provide strong privacy, but that as a solution for privacy entails a whole bunch of unpleasantness and NAT really isn't feasible for solving the privacy problem. I believe Id-Loc split will offer a better alternative.

> We tried in our PS document to mention the measures proposed within ILA/ILNP/LISP as state of the art.
>
> Do you agree that they are not yet sufficient to prevent the problems of inferring or tracking users' Identity and Location (with all the aspects of multiple flows, topology information etc.)?
> This is what we want to solicitate work on ...

I know that we're trying to address these in ILA. A well defined problem statement in this area would be good to use as a measure for such effort.

Tom

>
> Thanks!
> Best Regards
> Dirk
>
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Freitag, 4. Mai 2018 16:15
> To: von Hugo, Dirk <[e-mail]>
> Cc: Tom Herbert <[e-mail]>; Behcet Sarikaya 
> <[e-mail]>; 5GANGIP <[e-mail]>
> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]
>
> On Fri, May 4, 2018 at 5:51 AM,  <[e-mail]> wrote:
>> Thanks Tom,
>> for your helpful suggestions. We will discuss them and consider during update.
>> Just to clarify:
>> You want to day that Id-Loc approaches' primary benefits are elimination _or_ reduction of anchor points, as well as disassociating topology from IP addresses to facilitate efficient mobility and user privacy, right?
>>
> Dirk,
>
> I think those are problems that mapping systems can address. There's also the part about eliminating encapsulation and tunneling overhead which was mentioned in the document. On the other hand, a mapping system might introduce new problems like new DOS vectors that need to be considered.
>
> Tom
>
>
>
>> @All, please could you also comment on our text linked below? - you 
>> may even edit it directly in github to prevent misunderstanding on our side ;-) Thanks!
>> Best Regards
>> Dirk
>>
>> -----Original Message-----
>> From: 5gangip [mailto:[e-mail]] On Behalf Of Tom 
>> Herbert
>> Sent: Donnerstag, 3. Mai 2018 23:19
>> To: Behcet Sarikaya <[e-mail]>
>> Cc: 5GANGIP <[e-mail]>; Tom Herbert <[e-mail]>
>> Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem 
>> Statement]
>>
>> On Thu, May 3, 2018 at 11:52 AM, Behcet Sarikaya <[e-mail]> wrote:
>>>
>>>
>>> On Thu, May 3, 2018 at 12:46 PM, Tom Herbert <[e-mail]> wrote:
>>>>
>>>> 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://github.com/bsarikaya/atic/blob/master/atick_problemstatement.3.txt  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.
>>>
>>>
>>> Really?
>>>
>>>>
>>>> For a problem
>>>> statement, I still think there is too much focus on the solutions
>>>
>>>
>>
>> Hi Behcet,
>>
>>> You mean ILA, ILNP and LISP are solutions and PS draft talks a lot 
>>> about them?
>>>
>> Yes.
>>
>>>>
>>>> and
>>>> not nearly enough description of what the actual problems are to be 
>>>> solved.
>>>>
>>>
>>> I appreciate this comment but I don't get how we can remedy it.
>>> Can you please give some hints on what you want to see in the 
>>> document and in what order?
>>>
>> Offhand, I'd say that these are some problems of mapping systems or problems that might be addressed by mapping sytems:
>>
>> - If addresses (or device prefixes) are common between flows then a third party can make inferences (i.e. whether they're sourced from the same host). This gets into the problems of persistent identifiers.
>> This was touched upon indirectly in IDEAS with discussions about identity.
>> - If addresses contain fine grained topology then device location (and hence user location can be inferred). This gets to the problem that locators may very contain geographic location and hence are very sensistive data.
>> - If a cache is introduced into the data path (as might be the case in some mapping systems) then that in turn will introduce potential DOS attacks.
>> - Compromise of a mapping system is very bad since it would allow attackers to misdirect (I believe there was recently an incident where someone managed to spoof BGP to take control of traffic.
>> - More generally, what is the real problem is really being solved?
>>
>> Draft says:
>>
>> "In addition to increasing packet overhead due to encapsulation that may cause fragmentation and all related issues typical disadvantages of (especially static end-to-end) tunneling comprise inflexibility to properly react to dynamic changes of end points and potential on-path anchors."
>>
>> That's a bit misleading since not all Mapping Systems avoid encapsulation or tunneling. I believe that the primary benefits are elimination of reduction of anchor points, as well as disassciating topology from IP addressess to facilitate efficient mobility and user privacy..
>>
>> Tom
>>
>>> Maybe the first paragraph can be restructured to state the current 
>>> problem first and then mention proposed solutions?
>>>
>>> We can do that.
>>> In the following paragraphs we continue with each ID-Loc system and 
>>> try to describe the common problem of privacy based mapping system.
>>>
>>> I'll appreciate if you could tell how you would restructure it?
>>>
>>> Of course the same question to others who already comments or not, 
>>> please speak up!
>>>
>>>
>>> Thanks,
>>> Behcet
>>>
>>>>
>>>> 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://www.ietf.org/mailman/listinfo/ila
>>>> >>>
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > 5gangip mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/5gangip
>>>>
>>>> _______________________________________________
>>>> 5gangip mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/5gangip