Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Matthew Petach]

On Tue, Apr 14, 2020, 18:14 Matt Palmer  wrote:

> [Hideously mangled quoting fixed]
>
> On Tue, Apr 14, 2020 at 02:51:55PM +0530, Kushal R. wrote:
> > Matt Palmer wrote:
> > > On Mon, Apr 13, 2020 at 11:14:11PM +0530, Kushal R. wrote:
> > > > All abuse reports that we receive are dealt within 48 business hours.
> > >
> > > At eight business hours per calendar day, and five business days per
> > > (typical) calendar week, 48 business hours is...  a week and a bit,
> > > calendar wise.
> >
> > We are a 24x7 operation.
>
> Then why not just say "withing 48 hours", rather than the weaselish "48
> business hours"?  Makes it seem like you're trying to clever-word yourself
> an alibi.
>
> - Matt
>

The Internet never sleeps.

Every hour on the Internet *is* a business hour.

(If you think otherwise, there's a good chance you're not running a global
operation.)

Matt

Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Matt Palmer]

[Hideously mangled quoting fixed]

On Tue, Apr 14, 2020 at 02:51:55PM +0530, Kushal R. wrote:
> Matt Palmer wrote:
> > On Mon, Apr 13, 2020 at 11:14:11PM +0530, Kushal R. wrote:
> > > All abuse reports that we receive are dealt within 48 business hours.
> >
> > At eight business hours per calendar day, and five business days per
> > (typical) calendar week, 48 business hours is...  a week and a bit,
> > calendar wise.
>
> We are a 24x7 operation.  

Then why not just say "withing 48 hours", rather than the weaselish "48
business hours"?  Makes it seem like you're trying to clever-word yourself
an alibi.

- Matt

Re: Netflix Open Connect

[Darin Steffl]

Do you have 5 Gbps of traffic coming from Netflix yet? If not, you're not
at the size required to receive an OCA.

On Tue, Apr 14, 2020 at 3:13 PM John Alcock  wrote:

> I figure Netflix is busy just like every other company during the pandemic.
>
> I sent a request several weeks ago for Netflix OCA.  I have not heard
> anything.  Anyone from Netflix contact me off list?
>
> I am in charge of AS395437
>
> John
>


-- 
Darin Steffl
Minnesota WiFi
www.mnwifi.com
507-634-WiFi
 Like us on Facebook

Netflix Open Connect

[John Alcock]

I figure Netflix is busy just like every other company during the pandemic.

I sent a request several weeks ago for Netflix OCA.  I have not heard
anything.  Anyone from Netflix contact me off list?

I am in charge of AS395437

John

Re: Route aggregation w/o AS-Sets

[Christopher Morrow]

On Tue, Apr 14, 2020 at 3:02 PM Lars Prehn  wrote:
>
> Thanks for all the answers! I think I have one more detail I'd like to know.
>
> Lets say you own X/22. You have delegated X/23 to your customer, keeping the 
> other /23 for yourself. For some reason, your customer also owns and 
> announced (to you) all remaining IPs necessary to complete X/21.
>

(most of this is covered in petach's note actually... his 3 rules look
like they cover your cases)

Ideally if you have authorization to announce the /22 you do that.
If your customer announces the /23 good for them, you can choose to
hide this (if you don't think they have other paths where that /23
will be seen), you'd hide it through a bunch of different means, but
perhaps simplest is tag customer routes which are part of your
aggregates with a community and filter that community on exit to other
peers.

> Do you announce the aggregate X/21 (including addresses not associated with 
> you), the aggregate X/22 (only address belonging to you), or the more 
> specific route X/23 (including only addresses delegated from you to your 
> customer)?
>

You don't have authorization to announce the /21 (given your scenario
above) so please don't do that. That will make all manner of other
people made at you :(

I think your choices in your scenario are:
  1) announce the covering /22 only (use community example to filter
the customer's /23)
  2) announce the covering /22 and the customer originated /23

you should never announce a prefix for which you do not have
authorization to announce... this way leads to route hijacks.

> Best regards,
>
> Lars
>
>
> On 14.04.20 06:07, Christopher Morrow wrote:
>
> Don't user as-sets step one.
> Rpki does not understand how to express an as-sets' authorization.
>
> Why do you want to do this?
>
> On Mon, Apr 13, 2020, 13:34 Lars Prehn  wrote:
>>
>> Hi everyone,
>>
>> how exactly do you aggregate routes? When do you add the AS_SET
>> attribute, when do you omit it? How does the latter interplay with RPKI?
>>
>> Best regards,
>>
>> Lars
>>
>>

Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Tom Beecher]

Jonathan-

First time posts to the list are , pardon the phrase, quarantined out of
the gate. Once it's obvious that it's not spam or a problem individual,
that gets released and future messages go straight out.

This is still a manual process done by one person in the NANOG
organization, so it's not always that fast. You likely just got caught up
in that, and didn't do anything incorrectly.

On Tue, Apr 14, 2020 at 4:25 AM Jonathan M  wrote:

> My bad - This was not for Rich but for Kushal who initiated the thread
> taking the survey about us being "spammers". I'm contacting the
> administrator at Nanog.org now to figure out what I did wrong to properly
> post to the thread as I haven't used the mailing list before. Have a good
> day. Jonathan
>
> On Mon, Apr 13, 2020 at 9:55 PM Jonathan M  wrote:
>
>> This may not have been approved yet by the moderator but was sent to the
>> list about 30 minutes agoI'm sorry, but I'm just learning how to use
>> this list and I am concerned that my post was not properly sent--thus,
>> replying to the thread herethx
>>
>> Re: https://twitter.com/RiskIQ_IRT/status/1249721818602070016?s=20
>>
>> Hi, Rich,
>>
>> I hope you are well. If you ever encounter an incident that you think
>> could have been handled better on our end, we aspire to continuously
>> improve, and don't claim to be perfect.
>>
>> Rather than blocking our abuse notification to the abuse POC, it would be
>> better to let us know you have concerns so that we can improve our
>> communications. Blocking us on Twitter and shutting off communication is no
>> better than if we were to just send your customer's domain to a blacklist
>> without notifying you of a compromise so that it can possibly be patched.
>> Let's keep the overall goal in mind -- it's to make the internet safer by
>> flagging possible violations of your acceptable use policy that may lead to
>> compromised personal data or sensitive credentials of innocent visitors
>> online.
>>
>> Before anything is posted to Twitter, I personally review the history of
>> the event to see if we have exhausted all reasonable steps to mitigate
>> harmful cyber activity or operations on network infrastructure short of
>> always picking up the phone or using the fax. While we have attempted to do
>> that in the past for each event, there is just too much harmful cyber
>> activity going on for us to be relying on phone calls to try and reach the
>> abuse team to ask that our ticket be prioritised after an unreasonable
>> period of time has elapsed. We have thousands of escalations that we need
>> to handle and most of the time though not across the board, when we call to
>> reach the abuse teams, we are unsuccessful in reducing the time to
>> remediation.
>>
>> The goal is not to shame anyone per se. It's to create more transparency
>> regarding a problem that we all need to work together on. It's similar to
>> where nation state actors use public attribution as part of mitigation to
>> improve the Internet from cyber attacks. We did not block you on Twitter,
>> and after every tweet, we follow-up to the appropriate abuse point of
>> contact to raise visibility of the matter, as well as to the PR team, and
>> applicable computer emergency response teams as well as attorney generals
>> or other applicable authorities.
>>
>> We all need to work together. Please do not hesitate to contact me and I
>> will make sure we are meeting our end of aspiring to be a good partner, and
>> look forward to working with you as the need arises. Stay safe and healthy
>> in these challenging times, and we wish you the best.
>>
>> I'm happy to discuss offline as well. We can set up a time to discuss and
>> improve the mitigation workflow on both sides.
>>
>> Best regards,
>> Jonathan Matkowsky
>> VP, Digital Risk
>> RiskIQ, Inc.
>>
>>
>> On Mon, Apr 13, 2020 at 9:41 PM Tom Beecher  wrote:
>>
>>> I would agree that Twitter is not a primary place for abuse reporting.
>>>
>>> If they are reporting things via your correct abuse channel and you are
>>> indeed handling them within 48 business hours, then I would also agree this
>>> much extra spray and pray is excessive. However RiskIQ is known to be
>>> pretty responsible, so if they are doing this they likely feel like they
>>> are NOT getting appropriate responses from you and are resorting to
>>> scorched earth. Have you attempted to reach out to them and make sure they
>>> have the proper direct channel for abuse reporting?
>>>
>>> On Mon, Apr 13, 2020 at 1:45 PM Kushal R.  wrote:
>>>
 All abuse reports that we receive are dealt within 48 business hours.
 As far as that tweet is concerned, it’s pending for 16 days because they
 have been blocked from sending us any emails due to the sheer amount of
 emails they started sending and then our live support chats.

 We send our abuse reports to, but we don’t spam them to every publicly
 available email address for an organisation, it isn’t difficult to lo

Re: Route aggregation w/o AS-Sets

[Warren Kumari]

On Tue, Apr 14, 2020 at 1:04 AM Alejandro Acosta
 wrote:
>
> Hello Lars,
>
>  As a comment there is a draft that proposes to deprecate AS_SET
> https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/?include_text=1

Ta, thanks.
This completes the work started by RFC6472 - "Recommendation for Not
Using AS_SET and AS_CONFED_SET in BGP".

W



>
>
> Alejandro,
>
>
> On 4/11/20 7:09 AM, Lars Prehn wrote:
> > Hi everyone,
> >
> > how exactly do you aggregate routes? When do you add the AS_SET
> > attribute, when do you omit it? How does the latter interplay with RPKI?
> >
> > Best regards,
> >
> > Lars
> >
> >



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

Re: Route aggregation w/o AS-Sets

[Matthew Petach]

On Mon, Apr 13, 2020 at 10:35 AM Lars Prehn  wrote:

> Hi everyone,
>
> how exactly do you aggregate routes? When do you add the AS_SET
> attribute, when do you omit it? How does the latter interplay with RPKI?
>
> Best regards,
>
> Lars
>
>
I generally would use the atomic-aggregate knob to
generate aggregate routes for blocks I controlled,
when the downstream ASN information was not
necessary to propagate outside my network
(usually cases where I had multiple internal ASNs,
but all connectivity funneled though a single upstream pathway.)

If you have discrete downstream ASNs with potentially
different external pathways, you shouldn't be generating
aggregate routes that cover them; that's just bad routing 101.

Thus, my rules for aggregation always came down to:
1) is there more than one external/upstream pathway for the ASN and prefix?

If so, don't aggregate.
2) is redundant, reliable connectivity between all the external gateway
routers that would be announcing the aggregate?
If not, don't generate a covering aggregate.
3) If there's only a single upstream pathway through you for the ASN and
prefix,
and that won't be changing any time soon (eg, you have a collection of
downstream
datacenter with their own ASNs and prefixes, but they all route through a
common
backbone), then use the atomic-aggregate option to suppress the more
specific
AS_PATH information, and simply announce the space as a single aggregate
coming
from your backbone ASN.

That way, there's no confusion with RPKI and AS_SETS; all you're ever
announcing
are simple AS_PATHs for a given prefix.

Best of luck!

Matt

Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Kushal R.]

  
  

 I’ll reaching out to you off list.   
  

  
  

  
  
>   
> On Apr 14, 2020 at 1:55 PM,  mailto:jonatha...@riskiq.net)>  
> wrote:
>   
>   
>   
>   
> My bad - This was not for Rich but for Kushal who initiated the thread taking 
> the survey about us being "spammers". I'm contacting the administrator at 
> Nanog.org now to figure out what I did wrong to properly post to the thread 
> as I haven't used the mailing list before. Have a good day. Jonathan
>   
>   
>   
> On Mon, Apr 13, 2020 at 9:55 PM Jonathan M   (mailto:jonatha...@riskiq.net)>  wrote:
>   
> >   
> >   
> > This may not have been approved yet by the moderator but was sent to the 
> > list about 30 minutes agoI'm sorry, but I'm just learning how to use 
> > this list and I am concerned that my post was not properly sent--thus, 
> > replying to the thread herethx
> >   
> >
> >  Re:   https://twitter.com/RiskIQ_IRT/status/1249721818602070016?s=20   
> >
> >   
> > Hi, Rich,
> >   
> >
> >   
> > I hope you are well. If you ever encounter an incident that you think could 
> > have been handled better on our end, we aspire to continuously improve, and 
> > don't claim to be perfect.
> >   
> >
> >   
> > Rather than blocking our abuse notification to the abuse POC, it would be 
> > better to let us know you have concerns so that we can improve our 
> > communications. Blocking us on Twitter and shutting off communication is no 
> > better than if we were to just send your customer's domain to a blacklist 
> > without notifying you of a compromise so that it can possibly be patched. 
> > Let's keep the overall goal in mind -- it's to make the internet safer by 
> > flagging possible violations of your acceptable use policy that may lead to 
> > compromised personal data or sensitive credentials of innocent visitors 
> > online.
> >   
> >
> >   
> > Before anything is posted to Twitter, I personally review the history of 
> > the event to see if we have exhausted all reasonable steps to mitigate 
> > harmful cyber activity or operations on network infrastructure short of 
> > always picking up the phone or using the fax. While we have attempted to do 
> > that in the past for each event, there is just too much harmful cyber 
> > activity going on for us to be relying on phone calls to try and reach the 
> > abuse team to ask that our ticket be prioritised after an unreasonable 
> > period of time has elapsed. We have thousands of escalations that we need 
> > to handle and most of the time though not across the board, when we call to 
> > reach the abuse teams, we are unsuccessful in reducing the time to 
> > remediation.
> >   
> >
> >   
> > The goal is not to shame anyone per se. It's to create more transparency 
> > regarding a problem that we all need to work together on. It's similar to 
> > where nation state actors use public attribution as part of mitigation to 
> > improve the Internet from cyber attacks. We did not block you on Twitter, 
> > and after every tweet, we follow-up to the appropriate abuse point of 
> > contact to raise visibility of the matter, as well as to the PR team, and 
> > applicable computer emergency response teams as well as attorney generals 
> > or other applicable authorities.
> >   
> >
> >   
> > We all need to work together. Please do not hesitate to contact me and I 
> > will make sure we are meeting our end of aspiring to be a good partner, and 
> > look forward to working with you as the need arises. Stay safe and healthy 
> > in these challenging times, and we wish you the best.
> >   
> >
> >   
> > I'm happy to discuss offline as well. We can set up a time to discuss and 
> > improve the mitigation workflow on both sides.
> >   
> >
> >   
> > Best regards,
> >   
> > Jonathan Matkowsky
> >   
> > VP, Digital Risk
> >   
> > RiskIQ, Inc.
> >   
> >
> >   
> >
> > 
> >   
> >   
> > On Mon, Apr 13, 2020 at 9:41 PM Tom Beecherwrote:
> >   
> > >   
> > > I would agree that Twitter is not a primary place for abuse reporting.
> > >  
> > >
> > >   
> > > If they are reporting things via your correct abuse channel and you are 
> > > indeed handling them within 48 business hours, then I would also agree 
> > > this much extra spray and pray is excessive. However RiskIQ is known to 
> > > be pretty responsible, so if they are doing this they likely feel like 
> > > they are NOT getting appropriate responses from you and are resorting to 
> > > scorched earth.   Have you attempted to reach out to them and make sure 
> > > they have the proper direct channel for abuse reporting?   
> > >   
> > >   
> > >   
> > >   
> > > On Mon, Apr 13, 2020 at 1:45 PM Kushal R.   > > (mailto:kusha...@h4g.co)>  wrote:
> > >   
> > > >   
> > > >   
> > > >   
> > > >
> > > >  All abuse reports that we receive are dealt within 48 business hours. 
> > > > As far as that tweet is concerned, it’s pending for 16 days because 
> > > > they have been blocked from sending us any emails due to t

Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Kushal R.]

 
 

 We are a 24x7 operation.  
 

 
 

 
 
>  
> On Apr 14, 2020 at 12:20 PM,  mailto:mpal...@hezmatt.org)>  
> wrote:
>  
>  
>  
>  On Mon, Apr 13, 2020 at 11:14:11PM +0530, Kushal R. wrote:  >  All abuse 
> reports that we receive are dealt within 48 business hours. At eight business 
> hours per calendar day, and five business days per (typical) calendar week, 
> 48 business hours is... a week and a bit, calendar wise. - Matt 
>
>  
 
 
 

Re: Any Zayo peeps on the list?

[Ryan Gelobter]

I've found in the past that the Zayo escalation lists are very helpful in
getting something resolved. They may not answer but I've left messages
before and heard back from someone who can get stuff done.
https://tranzact.zayo.com/#!/escalation-lists

On Tue, Apr 14, 2020 at 1:45 AM Deepak Jain  wrote:

> Seconded -
>
> We have an issue that may become operational very soon. All of our
> contacts at Zayo have left/retired/etc including C-level types.
>
> Off list is great.
>
> Thanks in advance,
>
> Deepak
>
> -Original Message-
> From: NANOG  On Behalf Of Mike Lyon
> Sent: Tuesday, April 14, 2020 1:56 AM
> To: NANOG list 
> Subject: Any Zayo peeps on the list?
>
> Howdy!
>
> Any Zayo peeps on the list? Seeing some packet loss on your network and
> your NCC seems to be clueless.
>
> Please shoot me an email offlist.
>
> Thank You,
> Mike
>