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

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 08:54:23 -0700

Dino,

> 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?
>
RLOCs don't exist in ILA, that is a LISP term.

> You are missing the point. Forward to where? How?
>
I will try to answer your questions in as much detail as possible.

Here are the example cases that illustrate operation.

Case #1: A network has a single SIR prefix and one ILA-R and some
number of ILA-Ns. The ILA-Ns do not have a map cache and are only used
for SIR to ILA transformation.

The ILA-R advertises the SIR prefix in normal IP routing. It is the
router for the SIR prefix. Packets destined to an address with the SIR
prefix are thus routed the to ILA-R. Mapping entries are realized as
hosts routes in the ILA-R where the destination host is composed of
the SIR prefix and identifier. When an ILA-R receives a packet it
performs a route lookup. If the returned route is an ILA route then
the ILA transformation is performed where the SIR prefix is overridden
with the locator indicated in the route. The packet is then forwarded
back into the network. Normal IP routing forwards the packet to an
ILA-N corresponding to the locator (each ILA-N is assigned a unique
locator and routing is configured so that all packets with the locator
prefix in the destination address are forwarded to the ILA-N). At the
ILA-N, ILA to SIR transformation occurs so that original packet is
restored. The packet is then forwarded by the ILA-N to a downstream
destination (e.g. a UE).

If an ILA-R receives a packet and it finds there is no route for it
then it drops the packet. So if no ILA mapping exists for an
identifier address then the packet is dropped. The ILA-R contains all
the mappings for the ILA domain, if does not need to ask someone else
if it doesn't find a mapping. ILA-Rs are not map caches.

Case #2: A network has a single SIR prefix and multiple ILA-R and some
number of ILA-Ns. The ILA-Ns do not have a map cache and are only use
for SIR to ILA transformation.

This is the case where ILA-Rs are replicated for load and
availability. Each ILA-R advertises the SIR prefix in IP routing for
the network. Routing techniques of ECMP, shortest path, etc. are used
to route packets to the "nearest" ILA-R. Packet processing at each
ILA-R is the same as described in case #1.

Case #3: A network has a multiple ILA-R that shard the mapping entries
and some number of ILA-Ns. The ILA-Ns do not have a map cache and are
only use for SIR to ILA transformation. The low order bits of the SIR
prefix contain a shard index, the high order bits are common.

In this case the mapping table is not contained a single ILA-R, it is
sharded across some number of them. This might be done because the
table is too big, or for geographic locality, etc. Each shard is
associated with an index. SIR prefixes are composed of a common prefix
and the index in the low order bits (for instance index could be eight
bits). Each ILA-R then advertises its SIR prefix that includes its
index in IP routing. An ILA-R can also serve multiple shards so it may
advertise multiple prefixes in routing. Each shard may also be
replicated per case #2. Packet processing at each ILA-R is the same as
described in case #1.

* Note that none of these cases so far require a mapping cache. These
work for all packets regardless of the source. The sender may be local
to the network, or may be a host on the Internet.

Case 4: Map caches are enabled on ILA-Ns.

The map cache is implemented as host routes in an ILA-N similar to
ILA-R routes. When a packet is sent by a downstream device (e.g. a UE)
it traverses an ILA-N. The ILA-N performs a route lookup on the
packet. If an ILA route is found (a map cache hit) an ILA
transformation is performed an the packet is forwarded directly
towards the destination. If there is no ILA route (map cache miss),
then another route is found possibly the default route (remember these
are just normal route lookups). The packet is forward per the route
and since it still has a SIR prefix in the destination address it will
be forwarded to an ILA-R as described in case #1. The ILA-N does not
send a mapping request and does not remember the destination, it just
forwards without incurring any additional delay.

When ILA-Rs receive packets they transform and forward them as
described above. It MAY also send an ILA redirect. An ILA redirect can
only be sent to an ILA-N that is in the local ILA domain. To do this
the ILA-R performs a reverse lookup on the source address of the
received packets. If the lookup returns an ILA route then that will
contain the locator corresponding to the ILA-N for the sender. A
redirect message is sent the locator using ILAMP. This contains the
destination and the locator. When the ILA-N receives the redirect it
instantiates the routing table with an ILA route. Subsequent packets
then can use the route so that packets are router directly thereby
eliminating triangular routing.

There are other details about managing the ILA cache that are
described in draft-herbert-ila-ilamp-00.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 May 2018 12:10:15 -0400

Three reactions, all personal opinion (in case someone thinks my having 
helped chair the BoF is in any way relevant; it isn't):

1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the 
network.  Yes, you have provision for multiple of them sharing load. 
However, if that sharing gets to be a significant percentage of teh 
routers in the network, then there is no point in having bothered with 
ILA, you are just routing on the SIR.

2) As far as I can tell, when some ILA-N have caches, the ILA-R have no 
way of knowing whether the ILA-N have caches or not.  I can understand 
what happens if all ILA-N in a network have the same cache state (either 
they all have caches or they all do not have caches).  But I do not know 
what behavior you expect of an ILA-R if the ILA-N are not uniform. 
Given the hot-spot issue above, I think you need to really explain why 
ILA-N would not ahve caches.

3 - Minor) Your usage of "sharding" seems odd.  You are simply dividing 
the domain into address blocks, and distributing responsibility for 
those blocks separately.  In other contexts, sharding seems to be used 
more generally for having subcollections of the data which can be moved 
around.

Yours,
Joel

On 5/1/18 11:54 AM, Tom Herbert wrote:
> _______________________________________________
> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 09:37:54 -0700

On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern <[email-masked]> wrote:
> However, if that sharing gets to be a significant percentage of teh routers
> in the network, then there is no point in having bothered with ILA, you are
> just routing on the SIR.
>
Joel,

If you provision a network (or any system really) based on an
assumption that caches will always attain some hit rate this is a
fundamental mistake. One of the goals of a DOS attack would be to
drive the hit rate to zero in which case someone will be in a world of
hurt. Caches and DOS are a hard mix to contend with in nearly any
context, that's why it's much better to view caches as an optimization
rather than a requirement. They can be used to alleviate load, but
that cannot be relied upon.

I would also point out that caches only make sense as internal devices
for intra domain communications. This does not make sense for edge
routers that would need to create a working set cache for any
aribtrary load of traffic from the Internet.

> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no way
> of knowing whether the ILA-N have caches or not.  I can understand what
> happens if all ILA-N in a network have the same cache state (either they all
> have caches or they all do not have caches).  But I do not know what
> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the
> hot-spot issue above, I think you need to really explain why ILA-N would not
> ahve caches.
>
ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include
capabilities description.

> 3 - Minor) Your usage of "sharding" seems odd.  You are simply dividing the
> domain into address blocks, and distributing responsibility for those blocks
> separately.  In other contexts, sharding seems to be used more generally for
> having subcollections of the data which can be moved around.
>
Sharding is a database term that describes partitioning of the
database into smaller chunks for manageablibilty. That is what is
happening here (literally in the implementation since we are use a
database backend).

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 May 2018 12:58:55 -0400

If you do not use caches in your ILA-Ns (and yes, I understand your 
reasoning for not doing so), then you are constructing an overlay 
network.  One of the arguments I was given for using ILA was to enable 
direct forwarding of packets effectively without needing to have routing 
track the moving entities.  Without caches, you are pushing all the 
traffic through fewer entities.  And you seem to be either using a lot 
of ILA-R with concomitant information distribution or few ILA-R 
restricting the information distribution problem but instead having 
traffic concentration problems.

I understood from your earlier presentation that the ILA-r using the 
packet as a signal was to avoid dropping the first packet, and as a 
side-effect not needing a separate query message.
Now you seem to be saying that your think it important to support not 
having caches in the ILA-Ns, which is a VERY different trade-off.

Yours,
Joel

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 May 2018 12:16:05 -0500

On Tue, May 1, 2018 at 11:58 AM, Joel M. Halpern <[email-masked]>
wrote:

> reasoning for not doing so), then you are constructing an overlay network.

You mean it is kind of tunneling? I think this is a problem with all Id-Loc
systems except ILNP, I think.

One of the arguments I was given for using ILA was to enable direct
> forwarding of packets effectively without needing to have routing track the
> moving entities.  Without caches, you are pushing all the traffic through
> fewer entities.  And you seem to be either using a lot of ILA-R with
> concomitant information distribution or few ILA-R restricting the
> information distribution problem but instead having traffic concentration
> problems.
>

> having caches in the ILA-Ns, which is a VERY different trade-off.
I kind of support this idea ( not having caches) looking from privacy point
of view. A cache learned for one UE may have privacy issues for another UE.
So using that cache entry freely may not be a good idea.

Behcet

Yours,
>>> routers
>>> way
>>> the
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 10:16:29 -0700

On Tue, May 1, 2018 at 9:58 AM, Joel M. Halpern <[email-masked]> wrote:
> I understood from your earlier presentation that the ILA-r using the packet
> as a signal was to avoid dropping the first packet, and as a side-effect not
> needing a separate query message.
> Now you seem to be saying that your think it important to support not having
> caches in the ILA-Ns, which is a VERY different trade-off.
>
Joel,

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).

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 May 2018 13:22:25 -0400

I am not sure I follow.
If I am reading you right, you suggest that dropping cache usage during 
a DOS attack is a useful feature.
If the system is engineered to operate well using local caches in the 
ILA, then dropping cache usage would seem to result in a DOS attack on 
the ILA-R infrastructure as it will have to handle a sustained packet 
load much higher than its design target.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 May 2018 10:25:46 -0700

> I will try to answer your questions in as much detail as possible.

Thanks for more details.

> the SIR prefix and identifier. When an ILA-R receives a packet it

What do you mean by realized. Are host routes storedin ILR-R routers via a push protocol like ILAMP? You are going to push all host routes for all ILA-N nodes in the Internet?

> to the network, or may be a host on the Internet.

That is not clear for case #1. Answer my above question first.

> forwards without incurring any additional delay.

Okay, so the scale of the underlay depends on the number of SIR prefixes injected into the routing system. When using sharding, it could be a lot. This model is kinda a hybrid overlay/underlay where the underlay needs to take part in make packet forwarding work. So be it.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 May 2018 10:28:49 -0700

> If you do not use caches in your ILA-Ns (and yes, I understand your reasoning for not doing so), then you are constructing an overlay network.  One of the arguments I was given for using ILA was to enable direct forwarding of packets effectively without needing to have routing track the moving entities.  Without caches, you are pushing all the traffic through fewer entities.  And you seem to be either using a lot of ILA-R with concomitant information distribution or few ILA-R restricting the information distribution problem but instead having traffic concentration problems.

As well as suboptimal paths.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 May 2018 10:31:52 -0700

> dropped or indefinitely blocked on a cache miss).

Note in LISP, most of the time, prefixes are put in the cache. For ILA its mostly /128 host routes. And note, when an LISP ITR gets a Map-Reply, it can elect to put coarser EID-prefixes in the cache versus more specifics. Or, not elect to put anything in the cache and forward to PETRs (the same as your ILA-R routers) at the expense of suboptimal paths.

There are many options in LISP prevent DoS attack cache attacks. I don’t think that is true when caches are used in ILA.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 10:33:30 -0700

On Tue, May 1, 2018 at 10:22 AM, Joel M. Halpern <[email-masked]> wrote:
> I am not sure I follow.
> If I am reading you right, you suggest that dropping cache usage during a
> DOS attack is a useful feature.

No, that's not what I am saying. The DOS attack is on the cache in an
attempt to make every packet, including legitimate ones, take a cache
miss. This can be done by downstream devices flooding the cache node
where each packet contains a randomized address in the identifier
locator domain. In the case of ILA the packets are forwarded on the
cache miss and will be dropped if they are being sent to bogus
addresses (no route at ILA-R) packets that have routes are forwarded
as normal.

> If the system is engineered to operate well using local caches in the ILA,
> then dropping cache usage would seem to result in a DOS attack on the ILA-R
> infrastructure as it will have to handle a sustained packet load much higher
> than its design target.
>
Yes, the network needs to be properly provisioned (although these are
basically routers that would have to be in the path anyway). As I
said, if you're assuming that caches will always have some hit rate
that is the opening for a DOS attack.

Tom

>>> network.
>>> packet
>>> having
>>>>> happens if all ILA-N in a network have the same cache state (either
>>>>> they
>>>>> all
>>>>> hot-spot issue above, I think you need to really explain why ILA-N
>>>>> would
>>>>> not
>>>>> ahve caches.
>>>>>
>>>>> separately.  In other contexts, sharding seems to be used more
>>>>> generally
>>>>> for

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 10:42:06 -0700

> There are many options in LISP prevent DoS attack cache attacks. I don’t think that is true when caches are used in ILA.
That is correct. For ILA I would like to have a normative description
of how the protocol is intended to deal with DOS attack. IMO, when
someone asks what the DOS mitigation of a protocol is the answer
should be clear and concise.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 1 May 2018 10:54:48 -0700

> should be clear and concise.

And true.  ;-)

Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 11:44:21 -0700

> What do you mean by realized. Are host routes storedin ILR-R routers via a push protocol like ILAMP? You are going to push all host routes for all ILA-N nodes in the Internet?
That are host routes in the local ILA-R routing table.

> Okay, so the scale of the underlay depends on the number of SIR prefixes injected into the routing system. When using sharding, it could be a lot. This model is kinda a hybrid overlay/underlay wher…

Yes. It's already common technique with things like load balanceres
that on routing to distribute packets.

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Tue, 1 May 2018 19:02:18 +0000

You can't push routes to the Internet. ISP chose what they accept and whom they accept it from but typically nothing smaller than a /17 is allowed. Can we keep it real please!

-----Original Message-----
From: 5gangip <[email-masked]> On Behalf Of Tom Herbert
Sent: Tuesday, May 01, 2018 11:44 AM
To: Dino Farinacci <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; Behcet Sarikaya <[email-masked]>; Christian Huitema <[email-masked]>; [email-masked]; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] ILA forwaring [Was Re: Problem Statement]

On Tue, May 1, 2018 at 10:25 AM, Dino Farinacci <[email-masked]> wrote:
>> number of ILA-Ns. The ILA-Ns do not have a map cache and are only 
>> used for SIR to ILA transformation.
>>
>> router for the SIR prefix. Packets destined to an address with the 
>> SIR prefix are thus routed the to ILA-R. Mapping entries are realized 
>> as hosts routes in the ILA-R where the destination host is composed 
>> of the SIR prefix and identifier. When an ILA-R receives a packet it
>

>> work for all packets regardless of the source. The sender may be 
>> local to the network, or may be a host on the Internet.
>
>> ILA-R routes. When a packet is sent by a downstream device (e.g. a 
>> UE) it traverses an ILA-N. The ILA-N performs a route lookup on the 
>> then another route is found possibly the default route (remember 
>> these are just normal route lookups). The packet is forward per the 
>> route and since it still has a SIR prefix in the destination address 
>> it will be forwarded to an ILA-R as described in case #1. The ILA-N 
>> does not send a mapping request and does not remember the 
>> destination, it just forwards without incurring any additional delay.
>

Yes. It's already common technique with things like load balanceres that on routing to distribute packets.

> 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=rl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=NnvGYrVGFzM8
> rpmzW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=

_______________________________________________
5gangip mailing list
[email-masked]
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=rl1QvnuE017HX7WwFbX_YthGHFRrZVDpRcgsmaQkUGE&s=NnvGYrVGFzM8rpmzW7gypXA6_ZW6h0Bh0YcJdXpE-AI&e=

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 12:13:08 -0700

> You can't push routes to the Internet. ISP chose what they accept and whom they accept it from but typically nothing smaller than a /17 is allowed. Can we keep it real please!
We are not pushing route to the Internet. ILA in internal to a site.

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 1 May 2018 14:51:32 -0700

Tom,

These are very clear examples, thanks for your time putting them together.
Just one question below.

On Tue, May 1, 2018 at 8:54 AM, Tom Herbert <[email-masked]> wrote:

> received packets.

How does this work when the mapping information for the source address is
in a different ILA-R?

Thanks,
Alberto

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 1 May 2018 14:59:05 -0700

> 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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 15:32:58 -0700

On Tue, May 1, 2018 at 2:59 PM, Alberto Rodriguez-Natal
<[email-masked]> wrote:
> 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
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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 15:35:32 -0700

On Tue, May 1, 2018 at 2:51 PM, Alberto Rodriguez-Natal
<[email-masked]> wrote:
> How does this work when the mapping information for the source address is in
> a different ILA-R?
>
The ILA-R can query another ILA-R for the information (or just do a DB
lookup). This is not done in-line with the forwarding path.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 May 2018 18:49:07 -0400

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?

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 May 2018 16:20:12 -0700

On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern <[email-masked]> 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

>>> comparing
>>> mitigation

---

From: <[email-masked]>
Date: Thu, 3 May 2018 16:23:29 +0000

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.
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?
Thanks!
Best Regards
Dirk 

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Mittwoch, 2. Mai 2018 01:20
To: Joel M. Halpern <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; Alberto Rodriguez-Natal <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem Statement]

> 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

>>>> 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
>>>> 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).
>>>
>>>
>>>
>>> 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.
>>>
>>> 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,
>>
>> 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
>>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 May 2018 10:46:15 -0700

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

> 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

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 3 May 2018 21:23:23 +0000

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. 

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.
 
> Sent: Thursday, May 03, 2018 10:46 AM
> To: [email-masked]
> Cc: Tom Herbert <[email-masked]>; Joel M. Halpern
> <[email-masked]>; [email-masked]; Alberto Rodriguez-Natal
> <[email-masked]>; 5GANGIP <[email-masked]>
> > 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.
> 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
> >
> > Cc: Tom Herbert <[email-masked]>; [email-masked]; Alberto
> > Rodriguez-Natal <[email-masked]>; 5GANGIP <[email-masked]>
> > 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
> >>
> >>
> >>> 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
> >>> addresses DOS. It may seem counter-intuitive, but offering a bunch
> >>> of options really is not necessarily a good thing-- sometime less is
> >>> 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=
> >>>
> >>
> >
> 2paJIf4zw&m=zYkPItjuHMuGlJXD5K_4OstVOL1OQiA98fgBJ9c1Gjo&s=FnQLMire
> MiKC
> > SkPaOGFCybzDc2i2y49Cgtbl6mCLc9c&e=
> 
> 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=

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 May 2018 14:33:36 -0700

> 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 configurat…
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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 May 2018 17:45:47 -0400

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 May 2018 14:59:39 -0700

On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <[email-masked]> wrote:
> 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).
>
> 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.

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

>>> 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,
>>
>>> 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.
>>>
>>>>> I understand you correctly that DDOS attacks can never be completely
>>>>
>>>> prevented whatever protocol you use.
>>>>>
>>>> identity
>>>> statement, I still
>>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern <[email-masked]>
>>>>
>>>> wrote:
>>>>>>
>>>>> prevent
>>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert <[email-masked]>
>>>>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> important to eliminate the cost triangular routing (latency,
>>>>>>>>> average path
>>>>
>>>> load).
>>>>>>>>>
>>>>> man_listinfo_5gangip&d=DwICAg&c=LFYZ-
>>>>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 3 May 2018 22:53:31 +0000

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.

> From: Tom Herbert <[email-masked]>
> Sent: Thursday, May 03, 2018 3:00 PM
> Cc: FIGURELLE, TERRY F <[email-masked]>; [email-masked]; Tom
> Herbert <[email-masked]>; [email-masked]; Alberto Rodriguez-Natal
> > 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).
> >
> > 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,
> 
> 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
> infrastructure properly supports anti-spoofing. This basically this case has the
> same problem as in the Internet case.
> 
> Tom
> 
> >
> > Yours,
> > Joel
> >
> >
> >>> 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,
> >>
> >>> 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).
> >>>
> >>> (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.
> >>>
> >>> edges and leaves it at that. Or we could say all edges including RAN
> >>> if that makes people happy.
> >>>
> >>>> 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.
> >>>>
> >>>> and subsequently of DDOS protection also in the current version of
> >>>> our PS document https://urldefense.proofpoint.com/v2/url?u=https-
> >>>> 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
> >>>>>
> >>>>>> structurally the same, and even though if ILA were widely adopted
> >>>>>> not all ILA networks would be structurally the same, there should
> >>>>> _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 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--
> 3A__www.ietf.org_ma

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 May 2018 16:40:17 -0700

> No. We have always block unsolicited traffic from the Internet and it is too complicated to discuss here.
The fact that it is "too complicated to discuss" underscores the
problem. These are IETF protocols under discussion, and as such they
are supposed to work and be robust across a variety of use cases and
environments. While AT&T may have the staff to carefully anayze their
network and wade through all the complexity, not everyone has such
capabilities. This is probably a major reason why your argument
wouldn't help get LISP into Linux, if were accepted then people will
start using it without fully understanding the ramifications and
they'll be exposed to DOS-- all the protocol seems to say is there are
many options to chose from and you have to decide what's best for you.

As I said before, the answer to the question how does a protocol
address DOS should be clear and consise. If there is an answer for
LISP that does that I would like to see the details (maybe in the same
fashion as how I demonstrated operation of ILA cache).

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 May 2018 22:39:52 +0900

FWIW, I believe there are large operators that do not block unsolicited
inbound traffic to mobile networks. One of them is T-Mobile.

On Fri, May 4, 2018 at 7:53 AM, FIGURELLE, TERRY F <[email-masked]> wrote:

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 May 2018 07:44:27 -0700

On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
>> 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).
>>
>> UEs. So an
>> > >>>>>>>>> since packets can be dropped or indefinitely blocked on a
>> cache
>> > >>>>>>>>> miss).
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Tue, 8 May 2018 17:48:46 +0000

Nope, we handle QUIC. Spent lots of time with Google on that one. Many 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 <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 8, 2018 at 6:39 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
No. We have always block unsolicited traffic from the Internet and it is too complicated to discuss here.

> From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
> To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> Cc: FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tom
> Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alberto Rodriguez-Natal
> <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>
> On Thu, May 3, 2018 at 2:45 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> wrote:
> >> On Thu, May 3, 2018 at 2:23 PM, FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>
> wrote:
> >>>
> >>>> From: 5gangip <[email-masked]<mailto:[email-masked]>> On Behalf Of Tom Herbert
> >>>> To: [email-masked]<mailto:[email-masked]>
> >>>> Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern
> >>>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alberto Rodriguez-Natal
> >>>> <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>
> >>>> On Thu, May 3, 2018 at 9:23 AM,  <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>>
> >>>>> Hi Tom,
> >>>>> From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tom
> >>>>> Herbert
> >>>>> To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
> >>>>> Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alberto
> >>>>> Rodriguez-Natal <[email-masked]<mailto:[email-masked]>>; 5GANGIP
> >>>>> <[email-masked]<mailto:[email-masked]>>
> >>>>> On Tue, May 1, 2018 at 3:49 PM, Joel M. Halpern
> >>>>> <[email-masked]<mailto:[email-masked]>>
> >>>>
> >>>> wrote:
> >>>>>>
> >>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 1, 2018 at 10:16 AM, Tom Herbert
> <[email-masked]<mailto:[email-masked]>>
> >>>>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> [email-masked]<mailto:[email-masked]>
> >>>>> [email-masked]<mailto:[email-masked]>
> >>>> [email-masked]<mailto:[email-masked]>
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=y8MY6y9TJtKyf6UX754BJUGGvr5dtRNnAo2Xz7lVanM&s=uIPI2k2vLm8tJgWk_if9iUTx3lbIMyZMlmx0Mf0wmF0&e=>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 9 May 2018 08:08:15 -0700

On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F <[email-masked]> 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).

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 <[email-masked]> wrote:
>
>
>
>>> 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).
>>>
>>> > >>>>> <[email-masked]>
>>> > <[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 9 May 2018 08:21:02 -0700

> problems at the network layer (the aforementioned privacy in

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

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 9 May 2018 19:44:08 +0000

When you need to manage how usage is rated that plays a big role in how packets are handled. There it makes a whole lot of difference how the 3GPP policy rules are built. All 3GPP operators of significance do this and where you discard packets makes a huge difference. If you intentionally discard packets that have already been metered it is illegal in some countries.

But let’s take this back to where it began.

SPOOFING:

1. I’ve checked and NR edge can be or is covered by RAN (some RAN doesn’t exist yet). Thus it’s not possible for a UE to spoof IP addresses because the RAN can protect the upstream. It is already protected today by SGW/PGW and UPF.

You can also protect for 3GPP RAN and WiFi via ePDG by installing a policy rule. The rule has the valid subnet/prefix for the UE in the 5-Tuple. There is actually short hand in rule definitions which just substitutes the UE IP/subnet when it gets to PGW (before flowing down to RAN and UE).

2. EDGE use cases require tight coordination all the way down to transport to meet requirements. This includes definition of address ranges to be used in both directions exchanged between all parties involved. We actually have to go into great detail to make sure specific protocols can work. This also requires non-default CoS/QoS treatment which requires 3-tuple knowledge before the first packet. Thus we must know the flow before even the first packet is sent. Since you know what is valid, it trivial to block at the services edge what isn’t valid.

FYI

VoLTE smartphone requires a proxy on the general purpose APN. I checked and none of the vendors have or are working on a proxy that can get an unexpected SYN from services edge.

This is true for CGNAT too. You need some form of NAT traversal and these all require a packet up to get things plumbed.

Sent from my iPhone

On May 9, 2018, at 8:21 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 9, 2018 at 8:08 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, May 8, 2018 at 10:48 AM, FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>> wrote:
Nope, we handle QUIC. Spent lots of time with Google on that one. Many

Terry,

Tom

Tom

Back to unsolicited.

Sent from my iPhone

Tom

No. We have always block unsolicited traffic from the Internet and it is
too complicated to discuss here.

Simply stated the solution needs to be protected but we don't need tons
of detail in every standard.

-----Original Message-----
From: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 03, 2018 3:00 PM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tom

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).

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

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.

case has the

Tom

Yours,
Joel

Obviously if we remove GTP encapsulation that protect MAY need to
be

Terry,

believe that operators could require all down stream network that
are

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).

effort we drove (we donated the software to the open source
effort).

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.

be to augment an open source and if needed a 3GPP. I don't think we
need

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tom Herbert
Sent: Thursday, May 03, 2018 10:46 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alberto Rodriguez-Natal
<[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem
Statement]

Hi Tom,
I understand you correctly that DDOS attacks can never be
completely

It will however always remain related to known IP addresses and
the more

versatile these are handled a mitigation strategy could be
designed.

Dirk,

As you may have seen we mention improved handling of mapping
systems

Tom

Thanks!

Best Regards
Dirk

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Tom
Herbert
Sent: Mittwoch, 2. Mai 2018 01:20
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alberto
Rodriguez-Natal <[email-masked]<mailto:[email-masked]>>; 5GANGIP
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] [Ila] ILA forwaring [Was Re: Problem
Statement]

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?

DDOS attacks are structurally the same. An attacker is not going
to

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

Tom

Yours,
Joel

wrote:

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

3A__www.ietf.org_mail

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=ZjufntGbjGmejHErlAs_yMfAbCNZooJ8tcy1HcoFqYQ&s=TgdJsREjP7miSUi64kzMgXcx0cGF4oVYbcT14WlpKJE&e=

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 May 2018 17:51:19 +0900

On Wed, May 9, 2018 at 2:48 AM, FIGURELLE, TERRY F <[email-masked]> wrote:

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

Actually this is not a good thing at all. It means that any new video
service doesn't work on your network until you support it. This is pretty
much the definition of ossification of the Internet. It's also the reason
why the QUIC working group is doing its best to ensure that the protocol
provides zero cleartext information to the network, so the network cannot
make decisions like this.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 May 2018 07:24:18 -0700

> make decisions like this.

+1

I'd also point out that "All of us have special handling of traffic to
Amazon, Apple, Google and so
on" is the antithesis of net neutrality. IMO, it's reasonable to
discriminate types (video, bulk transfer, real time chat, etc.) of
traffic without discriminating based on the source of the traffic or
the transport protocol. This is what IP layer network signalling, like
in FAST as I mentioned, endeavours to do.

Tom