Subject: [5gangip] Problem Statement

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2018 09:30:17 -0500

Hello Folks,

As Cameron said, we need to have an actionable problem statement soon.
To that end Dirk and I have drafted one and so far got a few comments and
incorporated them.

We are attaching this document to this mail. This file and previous
versions are in our Github project called bsarikaya/atic.

We are calling for comments on this file.

This mail is also a call for volunteers to work on writing the problem
statement and other related documents such as requirements, currently used
techniques and issues, e.g. GTP in IETF draft format.

Now it is the time and we need to act.

Regards,

Dirk & Behcet

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Apr 2018 09:12:23 -0700

There is way to much detail here, particularly in the long
descriptions of proposed solutions. It doesn't crisply define what the
privacy problem is for mapping systems that needs to be addressed.

In any case, I will comment on the ILA section:

"3. ILA assumes a mapping system that contains identifier locator
values but since ILA currently does not define any control plane, no
other details have been defined. Privacy is addressed by way of UE
changing its address regularly by using a block of addresses. It is
observed that NAT can also provide address privacy but the use of NAT
is discouraged in IETF. Also UE needs to reestablish connections every
time it changes it address so it incurs delays which could be
significant in case of real-time communication. Recently it was
proposed to use LISP CP for ILA [draft-rodrigueznatal-ila-lisp-00]"

Most of this description is incorrect.

The mapping protocol for ILA is defined in draft-herbert-ila-ilamp-00.

In ILA we assume that the UE does not participate in the protocol.
Allowing UEs to see locators would easily allow third parties to infer
device location. Also, this makes little sense from a network
architecture POV. The UE is the mobile device in the network, the
network already must already implement a whole bunch of mobility
management and that includes tunneling to provide datapath which is
all transparent to the UE. Identifier/locator and ILA provides this
same functionality but can eliminate sub-optimal routing through
anchor points as well as overhead. This is far less architectural
churn than trying to somehow teach UEs, which in no way can be
trusted, to participate in mobility protocols.

Privacy in ILA comes from establishing privacy in IPv6 addresses (see
draft-herbert-ipv6-prefix-address-privacy).

UEs can be assigned mutiple addresses, different connections can
simultaneously use different addresses. See the description of this in
draft-herbert-ipv6-prefix-address-privacy.

draft-rodrigueznatal-ila-lisp-00 has been proposed, however I believe
that the DOS mitigations in the LISP control plane protocol is
insufficient. The primary problem is that the LISP control plane
defines a request/response protocol for address resolution to populate
a mapping cache. Until a resolution response is received packets for a
flow are blocked. This means a DOS attack on the cache has the worst
case effect of indefinitely blocking a legitimate flow.

In contrast, for ILA caches are only an optimization and are never
required for communications. On a cache miss, the a packet is
forwarded to an ILA router that will contain the mapping information
if it exists. This means a DOS attack on the cache has the worse case
effect of packets for a legitimate flow taking following suboptimal
routing.

Tom

On Fri, Apr 27, 2018 at 7:30 AM, Behcet Sarikaya <[email-masked]> wrote:
> We are attaching this document to this mail. This file and previous versions
> are in our Github project called bsarikaya/atic.
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2018 11:29:11 -0500

Hi Tom,

On Fri, Apr 27, 2018 at 11:12 AM, Tom Herbert <[email-masked]> wrote:

> descriptions of proposed solutions.

You mean too much? Agreed but eventually this document is going to be an
IETF draft, so the detail maybe warranted.

> It doesn't crisply define what the

Agreed, let's work on it.

> effect of packets for a legitimate flow taking following suboptimal
Tom, can you put these comments as edits on the file, like ILNP and LISP
sections?

Thanks,
Behcet

> versions

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 10:15:13 -0700

> case effect of indefinitely blocking a legitimate flow.

You’ll have the same problem on an ILA cacher if the entry doesn’t exist.

> effect of packets for a legitimate flow taking following suboptimal

LISP does the same thing.

There is no way you can differentiate ILA versus LISP with respect to this issue. They both have the exact same advantages and disadvantages.

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 27 Apr 2018 10:16:45 -0700

> case effect of indefinitely blocking a legitimate flow.

draft-rodrigueznatal-ila-lisp-01 describes how LISP can be used both in a
request/reply model as well as in a data-triggered notifications model.
Each model implies a different set of tradeoffs and which model to use
depends on the characteristics of the network. If a particular deployment
uses data-triggered notifications, the request/reply operations are
completely optional.

> effect of packets for a legitimate flow taking following suboptimal

As stated above, this model is also supported in LISP and discussed in
draft-rodrigueznatal-ila-lisp-01.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 10:23:25 -0700

Here are my comments to the LISP section:

> 2.	The LISP control-plane interface to the mapping system is defined in RFC6833. The LISP mapping transport system (LISP-DDT and LISP-ALT) are defined in RFC6836 and RFC8111, respectively. There is a MAP Server which is similar to DNS Server which publishes identifier 

This is incorrect. The xTRs publishes mappings to the mapping system by sending Map-Register messages to the map-servers(s).

I would just strike this sentence and continue with the next sentence. In fact, there is no value for this brief description to compare Map-Servers to DNS severs and Map-Resolvers to DNS resolvers.

> locator values in a mapping database. The Map-Server receives Map-Register messages from the data-plane nodes so they can publish their mappings. There is Map-Resolver which is similar to DNS resolver which accepts Map-Request messages for the EID and returns the corresponding EID-to-RLOC-set mappings by consulting mapping database system in a Map-Reply message.  All messages defined in the control plane are UDP messages.
> However, in LISP the identifier locator values are stored in data structures defined in the

Remove however, because it is not counter to the previous sentence. In fact, remove the entire sentence. If offers little value.

> RFCs above. All read and write operations to the mapping system are authenticated with shared-keys using sha256 as well as ECDSA similar to DNSSEC.   With so much of DNS flavor, similar concerns on the efficiency of write operations and the lack of privacy support for a given identifier value exist. 

The last sentence is incorrect. The mapping system is designed from scratch to allow dynamic writes. The DNS originally was designed to provision entries via configuration files. And then Dynamic DNS was added later. 

Strike the last sentence. It is misleading and false.

Dino

> On Apr 27, 2018, at 7:30 AM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hello Folks,
> 
> To that end Dirk and I have drafted one and so far got a few comments and incorporated them.
> 
> We are attaching this document to this mail. This file and previous versions are in our Github project called bsarikaya/atic.
> 
> This mail is also a call for volunteers to work on writing the problem statement and other related documents such as requirements, currently used techniques and issues, e.g. GTP in IETF draft format. 
> 
> <atick_problemstatement.2.txt>_______________________________________________
> 5gangip mailing list
> [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 10:26:58 -0700

Agree with Alberto.

Behcet, why are you constantly mis-representing text about LISP? Can you please be more prepared before writing text about LISP. And can you please include my comments when I send them to you. You seem to ignore them and I continue to repeat them, propogating mis-impressions of how LISP works.

Dino

> On Apr 27, 2018, at 10:16 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> 
> 
> draft-rodrigueznatal-ila-lisp-01 describes how LISP can be used both in a request/reply model as well as in a data-triggered notifications model.. Each model implies a different set of tradeoffs and which model to use depends on the characteristics of the network. If a particular deployment uses data-triggered notifications, the request/reply operations are completely optional.
> 
> As stated above, this model is also supported in LISP and discussed in draft-rodrigueznatal-ila-lisp-01.
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Apr 2018 10:44:36 -0700

On Fri, Apr 27, 2018 at 10:16 AM, Alberto Rodriguez-Natal
<[email-masked]> wrote:
> request/reply model as well as in a data-triggered notifications model..

As I mentioned offlist, if you think  that there are tradeoffs that
would jusitfy allowing the possibility of DOS then please _quantify_
the rationale.

In the case of public networks like 5G if end users are allowed drive
the can then I don't see any possible tradeoff that would be
warranted. Even if you were able to implement a bunch of mechanisms
that try to identify attackers, you cannot completely eliminate the
risk. We know attackers are clever, and it's not a question of "if",
but "when" they will figure out how to circumvent your mitigations and
launch a successful attack. And when it does happen we now have paying
customers being denied connectivity because of the DOS attack on a
cache. That is a regression from where we are today.

The better way to deal with DOS attacks on the Internet like this are
to limit the negative effects of the attack. That's what ILA does by
making caches optimizations in the path. If the negative effects are
limited that also gives less motivation for attackers to spend
resources on attack.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Apr 2018 11:13:09 -0700

> There is no way you can differentiate ILA versus LISP with respect to this issue. They both have the exact same advantages and disadvantages.

Yes,you can differentiate them. ILA never drops of blocks packets
becasue of cache miss; LISP allows that at least in certain
configurations. So the worst DOS attack in ILA results in sub-optimal
routing, worst case in LISP is indefinitely blocking packets.

Tom

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 27 Apr 2018 11:15:41 -0700

> cache. That is a regression from where we are today.

That is fine Tom. If you have a network deployment where DOS attacks are
feasible and cannot be mitigated/absorbed, just use data-triggered
notifications. LISP supports that as well :)

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 11:21:14 -0700

> routing, worst case in LISP is indefinitely blocking packets.

What does an ILA router (one that maintains a cache) do when there there is a map-cache miss?

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Apr 2018 11:37:09 -0700

> What does an ILA router (one that maintains a cache) do when there there is a map-cache miss?
ILA routers (ILA-R) are not caches. They contain their shard of the
mapping system.

ILA forwarding nodes (ILA-N) may have a cache. In the case of a cache
miss the packet is forwarded. It will go to an ILA router that can
perform ILA transformation. The ILA router may also send back an ILA
redirect to the forwarding node to populate the cache so that it can
perform the transformation on subsequent packets. ILA forwarding nodes
never drop or block packets because of a cache miss.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 12:01:30 -0700

> perform ILA transformation. The ILA router may also send back an ILA

And how does the ILA router get the locator?

> redirect to the forwarding node to populate the cache so that it can

Yes, but it has to know what the destination locator is. You keep leaving this information out whenever I ask you

> never drop or block packets because of a cache miss.

But then they don’t have a locator to transform or redirect. 

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 27 Apr 2018 12:11:30 -0700

> Yes, but it has to know what the destination locator is. You keep leaving this information out whenever I ask you
We are currently using a distributed key value store for that (redis
DB). ILA-Rs read the monitor their shard. Code is in
github.com/quantonium/ila if you want to take a look. IMO, using a KV
store for this as opposed to developing a new protocol is a good
direction. This way were leveraging all the recent development for
security, availability, reliability, replication, etc.

ILAMP defines the protocol between ILA-Rs and ILA-Ns primarily for
managing ILA-N caches.

> But then they don’t have a locator to transform or redirect.
The router can send them a redirect if it chooses. On a cache miss the
packet is forwarded like normal.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 12:26:14 -0700

> DB). ILA-Rs read the monitor their shard. Code is in

So does LISP.

> store for this as opposed to developing a new protocol is a good

I don’t want to look at code. I want you to explain clearly how a cache misser gets the RLOC. What if the identifier is not in its shard?

> ILAMP defines the protocol between ILA-Rs and ILA-Ns primarily for

I know that. You are not answering the key questions.

> packet is forwarded like normal.

You are missing the point. Forward to where? How?

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2018 14:42:52 -0500

On Fri, Apr 27, 2018 at 12:26 PM, Dino Farinacci <[email-masked]>
wrote:

> Agree with Alberto.
>
> Behcet, why are you constantly mis-representing text about LISP? Can you
> please be more prepared before writing text about LISP. And can you please
> include my comments when I send them to you. You seem to ignore them and I
> continue to repeat them, propogating mis-impressions of how LISP works.
>
>
Hi Dino,

Apologies.

If you don't want this to repeat then please take a few minutes and edit
the text yourself and send it to me.
Same comment for Tom.
Once we have those resolved,
I think that we can get much better feedback from the list

BTW, DNS-LISP Mapping system analogy was because of ILNP which just simply
uses DNS.

Regards,
Behcet

> > draft-rodrigueznatal-ila-lisp-01 describes how LISP can be used both in
> a request/reply model as well as in a data-triggered notifications model..

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Apr 2018 12:44:10 -0700

> Hi Dino,
> 
> Apologies.
> 
> If you don't want this to repeat then please take a few minutes and edit the text yourself and send it to me.

I did this twice to you privately.

> BTW, DNS-LISP Mapping system analogy was because of ILNP which just simply uses DNS.

Don’t follow the logic.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2018 15:02:22 -0500

Removed the cc list which was getting longer and longer.

> I did this twice to you privately.

The text I had contained what I thought you wanted me to write.
Your comments are sometimes ambiguous (sorry to say, no offense please),
like:

I would just strike this sentence and continue with the next sentence. In
fact, there is no value for this brief description to compare Map-Servers
to DNS severs and Map-Resolvers to DNS resolvers.

You were pointing to many sentences, I could not judge which sentence you
wanted me to remove.

That's why I am saying please put your words there so we know it precisely.

> > BTW, DNS-LISP Mapping system analogy was because of ILNP which just
Well it is not clear if LISP did adopt DNS as its mapping system or not. If
it is not DNS, what is it, that is not defined, at least as far as I can
see.
That's why, with atick, we should define it clearly including the
application area, clientele

Regards,
Behcet