Subject: Re: [lisp] Design discussion -06-(3) -> returnalloverlapping prefixes

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Jan 2010 11:24:25 -0500 (EST)

> From: Damien Saucez <[email-masked]>

    > every time you see this kind of attack, you generate a more-specific
    > mapping to isolate the attacked server. This mapping has a short TTL
    > and every body needs to know the mapping.

Not necessarily... the mapping could be source-specific (now that I think
about it, maybe that term better than 'partner-specific' - although I can
see good points to each, since 'source' could be ambiguous, it could refer
to either the traffic, or the mapping itself), so that only the ITR(s)
which are the source of the traffic get it.

(I see that later in the message you suggest basically this... I guess
source-specific mappings aren't well-disussed yet, that's an area we need
to improve.)

I don't think it would be too hard to figure out either the traffic
source, or the source ITR for that source, and make sure the source ITR
gets the updated mapping.

    > So when the new mapping is generated, every body will ask for the
    > new mapping, and this will be done every 10min in your example,
    > meaning that we effectively reduce the traffic to the destination
    > but we increase the load on the mapping system.

Well, true, but that load is many orders of magnitude less than most DDoS
attacks, which can run to something on the order of (I don't know the
current operational state in detail) tens of thousands of packets per
second.

    > Finally, if you move all the traffic to a black-hole, you also drop
    > the correct traffic, making the attack more efficient than without
    > the protection.

Yes, but the closer the block is to the source(s) of the DDoS is, the less
'real' traffic will be affected. And as to the 'real' sources which happen
to be co-located with the attack sources, they are stuck anyway, since
their traffic will be lost in the flood no matter what.

I gather that this proposal is very similar in its effects to what is done
for DDoS attacks now, it just uses a different mechanism (I think they use
explicit filters at the moment).

    > if you combine this attack with a spoof attack, you can isolate a
    > perfectly innocent site.

Spoofing is a real problem, but LISP cannot really solve it - it's a flaw
in the basic internetwork layer that spoofed traffic is possible.a

(Probably no router should forward a packet from a source for which the
reverse path is not out the interface the packet came in on - that would
kill all spoofing, except for neighbours on the same physical network,
right at the source. Although it would probably screw up when the
round-trip path has cycles in it, which I gather is common, so maybe this
isn't such a hot solution.)

As to LISP, ITRs could refuse to forward traffic from sources they are not
supposed to handle, but the problem is 'how do they know what sources they
are supposed to be handling'? If they are also an ETR, they know, but the
design does allow of exit-only (i.e. ITR-only) boxes; handling those would
mean more configuration (bad).

	Noel

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 7 Jan 2010 20:05:23 +0100

Hi Noel,

On Jan 7, 2010, at 17:24 , Noel Chiappa wrote:

[snip]

> are supposed to be handling'?

Can't they just check the lisp database? 

> If they are also an ETR, they know,

Isn't the contrary? Current spec do not mandate a mapping for the source address of a packet in the ETR (unless it is also an ITR and there is bidirectional traffic).

If the ETR has a mapping for the source address in its cache, then it do some sanity checks and eventually drop the packet.

.. or am I wrong somewhere?

Luigi

> but the
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: John Zwiebel <[email-masked]>
Date: Fri, 8 Jan 2010 10:54:20 -1000

On Jan 7, 2010, at 9:05 AM, Luigi Iannone wrote:

> Isn't the contrary? Current spec do not mandate a mapping for the  
> source address of a packet in the ETR (unless it is also an ITR and  
> there is bidirectional traffic).
>
> If the ETR has a mapping for the source address in its cache, then  
> it do some sanity checks and eventually drop the packet.
>

FWIW:
NXOS requires a lisp-database command on both the ITR and ETR
and checks that database to determine if the ITR is suppose to encap
packets for a given EID.

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 11 Jan 2010 11:14:46 +0100

> and checks that database to determine if the ITR is suppose to encap 

Same as OpenLISP ;-)

Luigi

---

From: Florin Coras <[email-masked]>
Date: Mon, 11 Jan 2010 11:34:28 +0100

Hello Luigi,

> .. or am I wrong somewhere?

I might be the one confused but isn't Noel speaking here about some sort
of uRPF? Meaning the ITR should not forward packets from within its
domain if the source EID of the packet is not from the domains
EID-prefix. But the boxes that are simple ITRs don't know the domain's
EID-prefix, only the ETRs know it (they use it in registrations at
Map-Servers).

.. or maybe I'm wrong :)

Florin

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 12 Jan 2010 10:07:25 +0100

Hi Florin,

On Jan 11, 2010, at 11:34 , Florin Coras wrote:

> of uRPF?

Oh, I see... I misunderstood.

> Meaning the ITR should not forward packets from within its

AFAIK the Cisco and the OpenLISP implementations do the check on the ITRs.
Further, even if the ITRs are not authoritative in replying to Map-Request, they still have the knowledge, since they have to have an entry in the LISP Database, otherwise how would an ITR select which RLOC to use as a source RLOC?

Or I am mistaken again? 

Luigi

---

From: Florin Coras <[email-masked]>
Date: Tue, 12 Jan 2010 10:55:40 +0100

Hi Luigi,

> Further, even if the ITRs are not authoritative in replying to Map-Request, they still have the knowledge, since they have to have an entry in the LISP Database, otherwise how would an ITR select w…

Good point. I managed to miss this due to the restricted model I was
considering.

> Or I am mistaken again? 
No, on the contrary :)

Florin

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Jan 2010 10:10:04 -0800

> Further, even if the ITRs are not authoritative in replying to Map- 
> Request, they still have the knowledge, since they have to have an  
> entry in the LISP Database, otherwise how would an ITR select which  
> RLOC to use as a source RLOC?

On the cisco implementation(s) we have a "database-mapping" command  
that is configured in both ITRs and ETRs. It configures the EID-prefix  
for this site as well as the local RLOCs used for the site. In an ITR- 
only system, we need the database-mapping command to know which  
packets are candidates for encapsulation (as Luigi refers to above).  
The ITRs also use the "database-mapping" command for setting locator- 
status-bits for packets they encapsulate.

Dino