Re: [EXTERNAL] Re: RTBH no_export

[John Kristoff]

On Mon, 4 Feb 2019 09:01:20 +
i3D.net - Martijn Schmidt  wrote:

> Cogent does let you use RTBH, but on a separate BGP session to a
> blackhole server. So it's a bit more hassle to set it up policy-wise,
> because it deviates from the standard. Same story for "former
> GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM
> and Asia.

There are other providers that do this besides those you listed.  I'm
not sure one way or the other is truly "the standard" approach, but
there may be an advantage and potentially good reason to have a separate
session.  If a no-multihop peering link/session is down, you might
still be able to establish a RTBH peering session via another path.
That may be what you need to get that direct neighbor back up.  :-)

John

RE: [EXTERNAL] Re: RTBH no_export

[Nikos Leontsinis]

I heard that before...

-Original Message-
From: Vincent Bernat 
Sent: Monday, February 4, 2019 9:48 AM
To: i3D.net - Martijn Schmidt 
Cc: Nikos Leontsinis ; Paul S. 
; nanog@nanog.org
Subject: Re: [EXTERNAL] Re: RTBH no_export

 ❦  4 février 2019 09:01 +00, i3D.net - Martijn Schmidt 
:

> Cogent does let you use RTBH, but on a separate BGP session to a
> blackhole server. So it's a bit more hassle to set it up policy-wise,
> because it deviates from the standard. Same story for "former
> GlobalCrossing", now CenturyLink's AS3549, which is still used for
> LATAM and Asia.

Cogent will "soon" support a blackhole community on regular BGP sessions. I've 
got this information a few months ago, so maybe just ask for it to make it 
happen sooner.
--
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)
This email is from Equinix (EMEA) B.V. or one of its associated companies in 
the territory from where this email has been sent. This email, and any files 
transmitted with it, contains information which is confidential, is solely for 
the use of the intended recipient and may be legally privileged. If you have 
received this email in error, please notify the sender and delete this email 
immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA 
Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.

Re: [EXTERNAL] Re: RTBH no_export

[Vincent Bernat]

 ❦  4 février 2019 09:01 +00, i3D.net - Martijn Schmidt 
:

> Cogent does let you use RTBH, but on a separate BGP session to a
> blackhole server. So it's a bit more hassle to set it up policy-wise,
> because it deviates from the standard. Same story for "former
> GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM
> and Asia.

Cogent will "soon" support a blackhole community on regular BGP
sessions. I've got this information a few months ago, so maybe just ask
for it to make it happen sooner.
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [EXTERNAL] Re: RTBH no_export

[i3D . net - Martijn Schmidt]

Cogent does let you use RTBH, but on a separate BGP session to a
blackhole server. So it's a bit more hassle to set it up policy-wise,
because it deviates from the standard. Same story for "former
GlobalCrossing", now CenturyLink's AS3549, which is still used for LATAM
and Asia.

Best regards,
Martijn

On 2/4/19 9:39 AM, Nikos Leontsinis wrote:
> This is a 20+ year old solution. Ugly because you will block good traffic and 
> on your effort to protect your network you will block legitimate traffic too 
> (satisfying the attacker) but most upstream providers
> will give  you a community to use (Cogent is a notable exception) and tag the 
> prefix under attack so that the attack will not reach your network.
> Sadly most IXs after 20 years they still don't understand the need for this 
> community but at least someone has written an rfc so that all of us use the 
> same community.
> At least we made some progress there...
>
> -Original Message-
> From: NANOG  On Behalf Of Paul S.
> Sent: Sunday, February 3, 2019 11:08 PM
> To: nanog@nanog.org
> Subject: [EXTERNAL] Re: RTBH no_export
>
> +1, exactly what we did. I also recommend implementing
> per-upstream/region blackhole communities (so your users can choose who to 
> blackhole as they see fit.)
>
> Often time, DDoS traffic comes from regions that do not intersect with 
> legitimate traffic.
>
> On 2/4/2019 03:15 午前, Tom Hill wrote:
>> On 31/01/2019 20:17, Nick Hilliard wrote:
>>> you should implement a different community for upstream blackholing.
>>> This should be stripped at your upstream links and replaced with the
>>> provider's RTBH community.  Your provider will then handle export
>>> restrictions as they see fit.
>> This works wonderfully, from past experience. :)
>>
> This email is from Equinix (EMEA) B.V. or one of its associated companies in 
> the territory from where this email has been sent. This email, and any files 
> transmitted with it, contains information which is confidential, is solely 
> for the use of the intended recipient and may be legally privileged. If you 
> have received this email in error, please notify the sender and delete this 
> email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 
> 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 
> 57577889.

RE: [EXTERNAL] Re: RTBH no_export

[Nikos Leontsinis]

This is a 20+ year old solution. Ugly because you will block good traffic and 
on your effort to protect your network you will block legitimate traffic too 
(satisfying the attacker) but most upstream providers
will give  you a community to use (Cogent is a notable exception) and tag the 
prefix under attack so that the attack will not reach your network.
Sadly most IXs after 20 years they still don't understand the need for this 
community but at least someone has written an rfc so that all of us use the 
same community.
At least we made some progress there...

-Original Message-
From: NANOG  On Behalf Of Paul S.
Sent: Sunday, February 3, 2019 11:08 PM
To: nanog@nanog.org
Subject: [EXTERNAL] Re: RTBH no_export

+1, exactly what we did. I also recommend implementing
per-upstream/region blackhole communities (so your users can choose who to 
blackhole as they see fit.)

Often time, DDoS traffic comes from regions that do not intersect with 
legitimate traffic.

On 2/4/2019 03:15 午前, Tom Hill wrote:
> On 31/01/2019 20:17, Nick Hilliard wrote:
>> you should implement a different community for upstream blackholing.
>> This should be stripped at your upstream links and replaced with the
>> provider's RTBH community.  Your provider will then handle export
>> restrictions as they see fit.
>
> This works wonderfully, from past experience. :)
>

This email is from Equinix (EMEA) B.V. or one of its associated companies in 
the territory from where this email has been sent. This email, and any files 
transmitted with it, contains information which is confidential, is solely for 
the use of the intended recipient and may be legally privileged. If you have 
received this email in error, please notify the sender and delete this email 
immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA 
Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.

Re: RTBH no_export

[Paul S.]

+1, exactly what we did. I also recommend implementing 
per-upstream/region blackhole communities (so your users can choose who 
to blackhole as they see fit.)


Often time, DDoS traffic comes from regions that do not intersect with 
legitimate traffic.


On 2/4/2019 03:15 午前, Tom Hill wrote:

On 31/01/2019 20:17, Nick Hilliard wrote:

you should implement a different community for upstream blackholing.
This should be stripped at your upstream links and replaced with the
provider's RTBH community.  Your provider will then handle export
restrictions as they see fit.


This works wonderfully, from past experience. :)

Re: RTBH no_export

[Tom Hill]

On 31/01/2019 20:17, Nick Hilliard wrote:
> you should implement a different community for upstream blackholing.
> This should be stripped at your upstream links and replaced with the
> provider's RTBH community.  Your provider will then handle export
> restrictions as they see fit.


This works wonderfully, from past experience. :)

-- 
Tom

Re: RTBH no_export

[Randy Bush]

> One more thing, RFC7999 has category Informational

and what exactly do you think that means.  in ietf terms, it is a formal
spec which does not specify a protocol.  it is still a formal spec.

randy

RE: RTBH no_export

[Michel Py]

> Alejandro Acosta wrote :
> One more thing, RFC7999 has category Informational

Point well taken.
A good thing, IMHO. If I remember correctly, I once opposed this text; not 
because it was a bad idea (standardizing is sometimes a good idea) but because 
I found it imprecise enough that it was not achieveing any goal and blurred the 
definition of what is a RTBH.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: RTBH no_export

[Alejandro Acosta]

One more thing, RFC7999 has category Informational

El 31/1/19 a las 16:21, Theodore Baschak escribió:
>
>> On Jan 31, 2019, at 1:28 PM, Roel Parijs > > wrote:
>>
>> For our BGP customers the problem is more complex. Our BGP customers
>> can send us the RTBH community, and we will drop the traffic at our
>> borders. Since we're only running a small network, we don't have the
>> capacity to deal with large attacks. If we would be able to forward
>> (and maybe alter it) this RTBH community towards our upstream
>> providers, the impact on our network would be limited. However, the
>> RFC states that an announcement tagged with the blackhole community
>> should get the no_advertise or no_export community.
>>
>> What is your opinion on this ?
>>
>
> In RFC7999 section 3.2 the first paragraph talks about what you're
> mentioning, NO_EXPORT and/or NO_ADVERTISE. It uses the word SHOULD.
> SHOULD has special meaning in RFCs, its not MUST. Its also not MAY.
> RFC2119 talks about the way these words should be interpreted. 
>
> In the next paragraph it says that extreme caution should be used when
> "purposefully propagating IP prefixes tagged with the BLACKHOLE
> community outside the local routing domain, unless policy explicitly
> aims at doing just that."
>
> So if your local routing policy is to propagate those blackholes on to
> your upstreams (and its mutually agreed and they're configured to
> accept them), then it can be done. Nothing technical in the RFC
> stopping that. 
>
> Theo
>

RE: RTBH no_export

[Michel Py]

> Roel Parijs wrote:
> To minimize the impact of DDoS, I have setup RTBH. For our own customers, we 
> can set the RTBH community ourselves towards our transit suppliers and
> this works well. For our BGP customers the problem is more complex. Our BGP 
> customers can send us the RTBH community, and we will drop the traffic
> at our borders. Since we're only running a small network, we don't have the 
> capacity to deal with large attacks. If we would be able to forward (and maybe
> alter it) this RTBH community towards our upstream providers, the impact on 
> our network would be limited. However, the RFC states that an announcement
> tagged with the blackhole community should get the no_advertise or no_export 
> community.

I think the RFC is flexible enough; it's more about what you have agreed with 
your upstream(s) in terms of what they will accept as blackholes routes.
Many upstreams will accept a destination-based blackhole if the prefix belongs 
to you, but accepting blackholes for other prefixes or accepting source-based 
blackholes requires a lot of trust. It's more a political issue than a 
technical one, as I see it.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: RTBH no_export

[Theodore Baschak]

> On Jan 31, 2019, at 1:28 PM, Roel Parijs  wrote:
> 
> For our BGP customers the problem is more complex. Our BGP customers can send 
> us the RTBH community, and we will drop the traffic at our borders. Since 
> we're only running a small network, we don't have the capacity to deal with 
> large attacks. If we would be able to forward (and maybe alter it) this RTBH 
> community towards our upstream providers, the impact on our network would be 
> limited. However, the RFC states that an announcement tagged with the 
> blackhole community should get the no_advertise or no_export community.
> 
> What is your opinion on this ?
> 

In RFC7999 section 3.2 the first paragraph talks about what you're mentioning, 
NO_EXPORT and/or NO_ADVERTISE. It uses the word SHOULD. SHOULD has special 
meaning in RFCs, its not MUST. Its also not MAY. RFC2119 talks about the way 
these words should be interpreted. 

In the next paragraph it says that extreme caution should be used when 
"purposefully propagating IP prefixes tagged with the BLACKHOLE community 
outside the local routing domain, unless policy explicitly aims at doing just 
that."

So if your local routing policy is to propagate those blackholes on to your 
upstreams (and its mutually agreed and they're configured to accept them), then 
it can be done. Nothing technical in the RFC stopping that. 

Theo

Re: RTBH no_export

[Nick Hilliard]

Roel Parijs wrote on 31/01/2019 19:28:

What is your opinion on this ?


you should implement a different community for upstream blackholing. 
This should be stripped at your upstream links and replaced with the 
provider's RTBH community.  Your provider will then handle export 
restrictions as they see fit.


Nick

Re: RTBH no_export

[Łukasz Bromirski]

> On 31 Jan 2019, at 20:28, Roel Parijs  wrote:
> 
> Hello NANOG,
> 
> To minimize the impact of DDoS, I have setup RTBH.
> For our own customers, we can set the RTBH community ourselves towards our 
> transit suppliers and this works well.
> 
> For our BGP customers the problem is more complex. Our BGP customers can send 
> us the RTBH community, and we will drop the traffic at our borders. Since 
> we're only running a small network, we don't have the capacity to deal with 
> large attacks. If we would be able to forward (and maybe alter it) this RTBH 
> community towards our upstream providers, the impact on our network would be 
> limited. However, the RFC states that an announcement tagged with the 
> blackhole community should get the no_advertise or no_export community.
> 
> What is your opinion on this ?

Community agreed between you and your peer is one thing, the other
is community agreed with your upstreams. If in addition you own the
customer IP space, it’s even less of a problem. 

And… if you upstreams agree to signal RTBH with you, it’s added bonus
for them - they’re stopping the flood at their own edges thanks to you.

win-win-win-drop ;)

— 
./