Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/8/19 7:11 PM, Christopher Morrow wrote:

when do we get back to stir/shaken?


that would be nice. i have a lot of questions about stir/shaken. 
attacking a problem statement rfc seems rather bizarre and unhinged to 
me. it outlines a lot of the objections i had to p-asserted-identity i 
had way back when.


Mike

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/8/19 6:46 PM, Keith Medcalf wrote:

On Monday, 8 July, 2019 19:28, Michael Thomas  wrote:


On 7/8/19 6:24 PM, Keith Medcalf wrote:

You are the only person who has mentioned reverse DNS lookups.

I'm only trying to guess what enlightens your misinformed world.

You claimed that the "root problem" was not knowing who the originator was.



I have claimed no such thing.

Mike

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Christopher Morrow]

when do we get back to stir/shaken?

On Mon, Jul 8, 2019 at 9:47 PM Keith Medcalf  wrote:
>
>
> On Monday, 8 July, 2019 19:28, Michael Thomas  wrote:
>
> >On 7/8/19 6:24 PM, Keith Medcalf wrote:
>
> >> You are the only person who has mentioned reverse DNS lookups.
>
> >I'm only trying to guess what enlightens your misinformed world.
>
> You claimed that the "root problem" was not knowing who the originator was.
>
> I claimed that you ALWAYS must know who the originator is -- they are at the 
> other end of the connection.
>
> You want to do a "reverse DNS lookup" for some reason.
>
> I still do not understand how doing a "reverse DNS lookup" will help with the 
> identity at the other end of the connection, since you already have to know 
> that identity in order to perform a reverse DNS lookup...
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
> lot about anticipated traffic volume.
>
>
>
>

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Monday, 8 July, 2019 19:28, Michael Thomas  wrote:

>On 7/8/19 6:24 PM, Keith Medcalf wrote:

>> You are the only person who has mentioned reverse DNS lookups.

>I'm only trying to guess what enlightens your misinformed world.

You claimed that the "root problem" was not knowing who the originator was.

I claimed that you ALWAYS must know who the originator is -- they are at the 
other end of the connection.

You want to do a "reverse DNS lookup" for some reason.

I still do not understand how doing a "reverse DNS lookup" will help with the 
identity at the other end of the connection, since you already have to know 
that identity in order to perform a reverse DNS lookup...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

DKIM brought nothing of any value since it cannot be used to refuse messages or 
abort before entering the DATA phase of the SMTP conversation.  You are, no 
matter what, committing resources to receiving the message and accepting 
responsibility for its delivery.  All you can do is fart about AFTER THE FACT, 
after it is already too late to reject the message.

Presently 99.99% of the SPAM that gets through to me is DKIM signed, yet it 
is still spam.  In fact, that DKIM signature provides absolutely nothing of 
value whatsoever, except to validate that the SPAM was unmolested between the 
sending MTA and me (which is unlikely anyway, and even more unlikely since the 
transport is almost always over a TLS channel which prevents tampering between 
the sending MTA and my MTA anyway).

Like I said, DKIM does nothing of value and is directed to solve a problem that 
does not, never has, and never will, exist in the real world.

Contrast this with SPF which does do something of value.  It enables the 
dropping of the session BEFORE the DATA phase if the envelope-from domain is 
not on the list of authorized MTA to be sending messages for that domain.  The 
only real problem with it is the allowance of prevarication in the data.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:24
>To: Valdis Klētnieks
>Cc: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 6:11 PM, Valdis Klētnieks wrote:
>> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
>>> On 7/8/19 5:54 PM, Keith Medcalf wrote:
 This is because DKIM was a solution to a problem that did not
>exist.


>>> ::eyeroll:: pray tell, how do you "always" know the identity of
>the MTA
>>> sending you a message?
>> It's more subtle than that - you always know the "identity" of the
>purported
>> MTA, because you know their IP address.  Whether "purported" is the
>same as
>> "legitimate" or "authorized" is a whole different kettle of
>fish
>>
>> Remember - port 25 is widely blocked precisely because there were
>always a
>> plenty supply of MTAs whose identity you knew, sending you spam
>from consumer
>> living rooms
>>
>
>Like I said, what DKIM brought is the ability to "blame me". knowing
>the
>IP address doesn't give you that in any useful way. Recall that trust
>is
>mainly a social construct, not a technical one. Bruce Schneier has
>written about that endlessly.
>
>Mike

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/8/19 6:24 PM, Keith Medcalf wrote:

You are the only person who has mentioned reverse DNS lookups.


I'm only trying to guess what enlightens your misinformed world.

Mike

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

You are the only person who has mentioned reverse DNS lookups.

However, it is true that you do in fact need to already know the identity of 
the sending MTA/MSA before you can do a "reverse DNS lookup".  What does this 
have to do with the price of tea in China?

And what value do you think a reverse DNS lookup adds to the identity 
information you already (obviously) have?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:12
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>Jon Callas, Eric Allman, the IETF security geek contingent and even
>me
>disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with
>you. Trillions of signed messages disagree with you. Steve Bellovin
>probably disagrees with you too since you seem to be under the
>illusion
>that a reverse DNS lookup tells you anything useful.
>
>::eyeroll::
>
>Mike
>
>On 7/8/19 6:06 PM, Keith Medcalf wrote:
>> Wow!
>>
>> You must not know much about networking or programming if you do
>not know how to ask the OS to tell you the address/port associated
>with the "other end" of a TCP connection.  Obviously you know who is
>sending the message since they are in bidirectional communication
>with you at the time you are receiving the message, and you need to
>know where to send the "carry on James" prompts to get them to send
>more data...
>>
>> Therefore you always know who submitted a message.
>>

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/8/19 6:11 PM, Valdis Klētnieks wrote:

On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:

On 7/8/19 5:54 PM, Keith Medcalf wrote:

This is because DKIM was a solution to a problem that did not exist.



::eyeroll:: pray tell, how do you "always" know the identity of the MTA
sending you a message?

It's more subtle than that - you always know the "identity" of the purported
MTA, because you know their IP address.  Whether "purported" is the same as
"legitimate" or "authorized" is a whole different kettle of fish

Remember - port 25 is widely blocked precisely because there were always a
plenty supply of MTAs whose identity you knew, sending you spam from consumer
living rooms



Like I said, what DKIM brought is the ability to "blame me". knowing the 
IP address doesn't give you that in any useful way. Recall that trust is 
mainly a social construct, not a technical one. Bruce Schneier has 
written about that endlessly.


Mike

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

Jon Callas, Eric Allman, the IETF security geek contingent and even me 
disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with 
you. Trillions of signed messages disagree with you. Steve Bellovin 
probably disagrees with you too since you seem to be under the illusion 
that a reverse DNS lookup tells you anything useful.


::eyeroll::

Mike

On 7/8/19 6:06 PM, Keith Medcalf wrote:

Wow!

You must not know much about networking or programming if you do not know how to ask the OS to tell 
you the address/port associated with the "other end" of a TCP connection.  Obviously you 
know who is sending the message since they are in bidirectional communication with you at the time 
you are receiving the message, and you need to know where to send the "carry on James" 
prompts to get them to send more data...

Therefore you always know who submitted a message.

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Valdis Klētnieks]

On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
> On 7/8/19 5:54 PM, Keith Medcalf wrote:

> > This is because DKIM was a solution to a problem that did not exist.
> >
> >
> ::eyeroll:: pray tell, how do you "always" know the identity of the MTA
> sending you a message?

It's more subtle than that - you always know the "identity" of the purported
MTA, because you know their IP address.  Whether "purported" is the same as
"legitimate" or "authorized" is a whole different kettle of fish

Remember - port 25 is widely blocked precisely because there were always a
plenty supply of MTAs whose identity you knew, sending you spam from consumer
living rooms



pgpxMvj72j5qd.pgp
Description: PGP signature

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

Wow!

You must not know much about networking or programming if you do not know how 
to ask the OS to tell you the address/port associated with the "other end" of a 
TCP connection.  Obviously you know who is sending the message since they are 
in bidirectional communication with you at the time you are receiving the 
message, and you need to know where to send the "carry on James" prompts to get 
them to send more data...

Therefore you always know who submitted a message.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: Michael Thomas [mailto:m...@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 18:58
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 5:54 PM, Keith Medcalf wrote:
>> On Monday, 8 July, 2019 18:08, Michael Thomas 
>wrote:
>>
>>> when we did DKIM back in the day, almost nobody was requiring SMTP
>>> auth which meant the providers could say "blame me" via the DKIM
>>> signature, >but couldn't really take much action since they didn't
>>> know who has doing it.
>> This is because DKIM was a solution to a problem that did not
>exist.  You always know the identity of the MTA sending you a
>message, there never was a need for DKIM.  It was a solution to a
>problem that does not and did not nor will ever exist.
>>
>>
>::eyeroll:: pray tell, how do you "always" know the identity of the
>MTA
>sending you a message?
>
>
>Mike

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/8/19 5:54 PM, Keith Medcalf wrote:

On Monday, 8 July, 2019 18:08, Michael Thomas  wrote:


when we did DKIM back in the day, almost nobody was requiring SMTP
auth which meant the providers could say "blame me" via the DKIM
signature, >but couldn't really take much action since they didn't
know who has doing it.

This is because DKIM was a solution to a problem that did not exist.  You 
always know the identity of the MTA sending you a message, there never was a 
need for DKIM.  It was a solution to a problem that does not and did not nor 
will ever exist.


::eyeroll:: pray tell, how do you "always" know the identity of the MTA 
sending you a message?



Mike

RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Keith Medcalf]

On Monday, 8 July, 2019 18:08, Michael Thomas  wrote:

>when we did DKIM back in the day, almost nobody was requiring SMTP
>auth which meant the providers could say "blame me" via the DKIM
>signature, >but couldn't really take much action since they didn't
>know who has doing it.

This is because DKIM was a solution to a problem that did not exist.  You 
always know the identity of the MTA sending you a message, there never was a 
need for DKIM.  It was a solution to a problem that does not and did not nor 
will ever exist.

>we sort of took a leap of faith that that would happen.
>nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
>have no idea whether DKIM was in any way a motivating factor, but it
>did happen in the meantime.

This happened long long long before DKIM was even a wet spot on the sheets.

>i know the parallels here are not exact (is it really PRI's that are
>the source of most of the spam?) , but it's maybe a little premature to
>completely write off the providers for doing the Right Thing. putting
>the "blame me" badge on might give them some incentive to clean up
>their act. as with email spam, there is no silver bullet of course.

The solution is to disallow spoofing.  If the "pretty overlay information" does 
not equal the "billing information" then do not permit the call to be made.  
Easy Peasy.  However, this will interfere with the carriers ability to make 
money since the ability to make money depends on being in cahoots with the 
fraudsters.  Making it such that the Directors and Officers those carriers in 
cahoots suffer the death penalty (or life imprisonment) will solve the problem 
in an afternoon, but it will not happen because the cahooteers' (those 
Directors and Officers) own the slimy politicians needed to implement the cure.

>fwiw, the stir/shaken problem statement is a good read.

>https://datatracker.ietf.org/doc/rfc7340/

Not a bad work of complete fiction!

Of course, the "root cause" can be found at the very beginning of the thing 
where it is pointed out that there are reasons for providing false data, and 
that since "the other guy" allows the presentation of false data, we should too 
otherwise we will go out of business.  Once this "root cause" is accepted, then 
the inevitable ensues ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: QoS for Office365

[cyrus ramirez via NANOG]

Implement Quality of Service in Microsoft Teams  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Implement Quality of Service in Microsoft Teams
 
Prepare your organization's network for Quality of Service (QoS) in Microsoft 
Teams.
  |   |

  |

  |

  


Sent from Yahoo Mail on Android 
 
  On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka wrote:   

On 8/Jul/19 18:18, Jared Mauch wrote:

>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.
>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.

In some cases, the motivation for these requirements is fueled by trying
to outsmart your competitors.

I just don't know of a reliable, contractual way that you can use QoS to
say your DIA or IP Transit service is better than that of your competitor.

Mark.
  

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

when we did DKIM back in the day, almost nobody was requiring SMTP auth 
which meant the providers could say "blame me" via the DKIM signature, 
but couldn't really take much action since they didn't know who has 
doing it. we sort of took a leap of faith that that would happen.  
nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i 
have no idea whether DKIM was in any way a motivating factor, but it did 
happen in the meantime.


i know the parallels here are not exact (is it really PRI's that are the 
source of most of the spam?) , but it's maybe a little premature to 
completely write off the providers for doing the Right Thing. putting 
the "blame me" badge on might give them some incentive to clean up their 
act. as with email spam, there is no silver bullet of course.


fwiw, the stir/shaken problem statement is a good read.

https://datatracker.ietf.org/doc/rfc7340/

Mike

On 7/8/19 2:53 PM, Peter Beckman wrote:

Summary:

SHAKEN/STIR does nothing but sign a call by a carrier that can be 
verified
by another carrier that they signed it. It does nothing to stem 
Robocalls.


Discussion:

All SHAKEN/STIR does is have the originating carrier of a call to
cryptographically attest, to some degree, that the call originated from
their network.

One example given was that SHAKEN/STIR can verify that it is really 
the IRS

calling.

But that would require knowledge of which carrier currently serves the 
IRS,

and that the IRS use that same carrier for both inbound AND outbound
calling, and that the carrier publishes some record that it is the 
carrier

of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR.

If Carrier A is taking calls from a spammer and implements 
SHAKEN/STIR, and
their termination Carrier B have also implemented SHAKEN/STIR 
verification
and trusted Carrier A's certificate, all that occurs is that Carrier A 
says

"this call is trustworthy" and Carrier B verifies that Carrier A said so
and completes the call.

Carrier A can lie all they want, as they do now, providing a false "Full
Attestation" that the "service provider has authenticated the calling 
party

and they are authorized to use the calling number." But there's no proof
that they are telling the truth, and no way for any other intermediate
carrier to verify anything other than the originating carrier.

Now if Carrier B decides not to trust Carrier A anymore, they can stop
trusting their cert and drop calls. Which Carrier B can do today by
terminating the relationship with Carrier A.

I still don't see how this will stop CallerID spoofing or Robocalls.
Carrier B can block Carrier A at anytime. Carrier A can attest that any
call originating from it is authorized to use that number. Plus then
there's a ton of intermediates that aren't even addressed here. Do all 
the
Intermediates also need to implement SHAKEN/STIR such that the SIP 
Identity

header is passed onto the next leg? If the intermediate drops the header,
does the call fail?

And spammers already use real, leased phone numbers for Robocalls. We
had a client come to us who wanted 5,000 new/different and not recycled
phone numbers across the US each month. When prompted about how they'd be
used, they just needed inbound calls and SMS messages routed to their
switch hosted at a cloud provider, outbound calls would be made through
another carrier.

With SHAKEN/STIR, these calls would show up as "Authenticated" as the
client could tell their Carrier C that these 5,000 phone numbers were
theirs, and Carrier C could do a "Full Attestation" SIP Identity 
header and

the spam calls would show up as "Verified." But still Robocalls, just
Verified Robocalls.

We declined to do business with this client.

In summary, SHAKEN/STIR seems to do nothing but be some extra technical
work.

Please correct me if I'm missing a key piece of this.

I'm in DC, I'm going to try to attend this summit.

https://transnexus.com/whitepapers/understanding-stir-shaken/

Beckman

On Mon, 8 Jul 2019, Jay R. Ashworth wrote:


- Original Message -

From: "Sean Donelan" 



I don't think SHAKEN/STIR really addresses the root problems with
spoofing phone numbers, anymore than any of the BGP proposals for 
spoofing

IP addresses.

Nevertheless, the FCC wants to be seen as doing something.  So Chairman
Pai is having a summit to show all the progress.

On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
focused on the industry’s implementation of SHAKEN/STIR, a caller ID
authentication framework to combat illegal robocalls and caller ID
spoofing.  Chairman Pai expects major voice service providers to deploy
the SHAKEN/STIR framework this year.   The summit will showcase the
progress that major providers have made toward reaching that goal and
provide an opportunity to identify any challenges to implementation and
how best to overcome them.


Well, y'know, it's been 10 years since I originated calls to LD 
carriers.


But when I did, 3 of my 

RE: QoS for Office365

[Keith Medcalf]

Using Orifice 342 will hurt you.

Packet loss (the more the better) will only help you.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka
>Sent: Monday, 8 July, 2019 15:50
>To: Robert Webb
>Cc: NANOG list
>Subject: Re: QoS for Office365
>
>
>
>On 8/Jul/19 21:03, Robert Webb wrote:
>> I took the OP's request as for doing QoS at the edge of their
>network
>> and not necessarily the entire path.
>
>Indeed, but even then, you could be handing off the traffic to a
>downstream customer, and can't guarantee what they do to those ToS
>fields.
>
>
>>
>> As another person stated, the real answer is to add more bandwidth
>if
>> you are having to QoS to Office365 because it is affecting other
>> internet based services.
>
>Yes and no.
>
>More bandwidth never hurt anyone, but packet loss in the remote
>network
>toward the cloud will hurt you.
>
>Mark.

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 00:35, Warren Kumari wrote:

> I disagree -- you *can* guarantee what someone else will do with your
> ToS fields... they will A: ignore them and / or B: scribble all
> over them.

I'll rephrase... you can't guarantee that a remote network will handle
your packets the way you intend.


> At a previous employer (AOL, doing VoIP for customer service / call
> centers, ~2004) we had a number of contractual agreements with
> multiple providers to honor our QoS markings -- as far as I could tell
> (marking test traffic under congestion events) only one of about seven
> did anything at all with the marking, and that wasn't enough to make
> any difference... I briefly toyed with the idea of asking for some
> money back / trying to enforce the terms of the agreements, but
> figured that there wasn't much point - expecting QoS to work in
> someone else's network based upon your markings seems like a fool's
> errand.

Agreed.

I would, though, say that I admire that you went as far as ringing up
contracts on the back of this.

Mark.

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  wrote:
>
>
>
> On 8/Jul/19 21:03, Robert Webb wrote:
> > I took the OP's request as for doing QoS at the edge of their network
> > and not necessarily the entire path.
>
> Indeed, but even then, you could be handing off the traffic to a
> downstream customer, and can't guarantee what they do to those ToS fields.

I disagree -- you *can* guarantee what someone else will do with your
ToS fields... they will A: ignore them and / or B: scribble all
over them.

At a previous employer (AOL, doing VoIP for customer service / call
centers, ~2004) we had a number of contractual agreements with
multiple providers to honor our QoS markings -- as far as I could tell
(marking test traffic under congestion events) only one of about seven
did anything at all with the marking, and that wasn't enough to make
any difference... I briefly toyed with the idea of asking for some
money back / trying to enforce the terms of the agreements, but
figured that there wasn't much point - expecting QoS to work in
someone else's network based upon your markings seems like a fool's
errand.

W

>
>
> >
> > As another person stated, the real answer is to add more bandwidth if
> > you are having to QoS to Office365 because it is affecting other
> > internet based services.
>
> Yes and no.
>
> More bandwidth never hurt anyone, but packet loss in the remote network
> toward the cloud will hurt you.
>
> Mark.



-- 
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: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Peter Beckman]

Summary:

SHAKEN/STIR does nothing but sign a call by a carrier that can be verified
by another carrier that they signed it. It does nothing to stem Robocalls.

Discussion:

All SHAKEN/STIR does is have the originating carrier of a call to
cryptographically attest, to some degree, that the call originated from
their network.

One example given was that SHAKEN/STIR can verify that it is really the IRS
calling.

But that would require knowledge of which carrier currently serves the IRS,
and that the IRS use that same carrier for both inbound AND outbound
calling, and that the carrier publishes some record that it is the carrier
of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR.

If Carrier A is taking calls from a spammer and implements SHAKEN/STIR, and
their termination Carrier B have also implemented SHAKEN/STIR verification
and trusted Carrier A's certificate, all that occurs is that Carrier A says
"this call is trustworthy" and Carrier B verifies that Carrier A said so
and completes the call.

Carrier A can lie all they want, as they do now, providing a false "Full
Attestation" that the "service provider has authenticated the calling party
and they are authorized to use the calling number." But there's no proof
that they are telling the truth, and no way for any other intermediate
carrier to verify anything other than the originating carrier.

Now if Carrier B decides not to trust Carrier A anymore, they can stop
trusting their cert and drop calls. Which Carrier B can do today by
terminating the relationship with Carrier A.

I still don't see how this will stop CallerID spoofing or Robocalls.
Carrier B can block Carrier A at anytime. Carrier A can attest that any
call originating from it is authorized to use that number. Plus then
there's a ton of intermediates that aren't even addressed here. Do all the
Intermediates also need to implement SHAKEN/STIR such that the SIP Identity
header is passed onto the next leg? If the intermediate drops the header,
does the call fail?

And spammers already use real, leased phone numbers for Robocalls. We
had a client come to us who wanted 5,000 new/different and not recycled
phone numbers across the US each month. When prompted about how they'd be
used, they just needed inbound calls and SMS messages routed to their
switch hosted at a cloud provider, outbound calls would be made through
another carrier.

With SHAKEN/STIR, these calls would show up as "Authenticated" as the
client could tell their Carrier C that these 5,000 phone numbers were
theirs, and Carrier C could do a "Full Attestation" SIP Identity header and
the spam calls would show up as "Verified." But still Robocalls, just
Verified Robocalls.

We declined to do business with this client.

In summary, SHAKEN/STIR seems to do nothing but be some extra technical
work.

Please correct me if I'm missing a key piece of this.

I'm in DC, I'm going to try to attend this summit.

https://transnexus.com/whitepapers/understanding-stir-shaken/

Beckman

On Mon, 8 Jul 2019, Jay R. Ashworth wrote:


- Original Message -

From: "Sean Donelan" 



I don't think SHAKEN/STIR really addresses the root problems with
spoofing phone numbers, anymore than any of the BGP proposals for spoofing
IP addresses.

Nevertheless, the FCC wants to be seen as doing something.  So Chairman
Pai is having a summit to show all the progress.

On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
focused on the industry’s implementation of SHAKEN/STIR, a caller ID
authentication framework to combat illegal robocalls and caller ID
spoofing.  Chairman Pai expects major voice service providers to deploy
the SHAKEN/STIR framework this year.   The summit will showcase the
progress that major providers have made toward reaching that goal and
provide an opportunity to identify any challenges to implementation and
how best to overcome them.


Well, y'know, it's been 10 years since I originated calls to LD carriers.

But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
that weren't for 10D calling numbers *they had assigned us* (and hence I
had to work that out with them to prove that *someone* had)...

nd the other 2 didn't give a crap.  I could send them anything -- even calls
with CNID that wasn't a valid NANP address (4th digit 1, frex).

Since nearly all of this is being originated over PRIs to LD carriers, right;
maybe if the FCC just threatened the LD carriers who do not do the calling
number legitimacy enforcement the regs (I think) already require them to do...?

Cheers,
-- jra
--
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274



---
Peter 

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 22:01, adamv0...@netconsultings.com wrote:

> And yet the SD-WAN promising MPLS experience over the internet and other BS 
> sells like crazy ;)

Where have we seen that before...

Still waiting for the ATM port on my laptop :-).

Mark.

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 21:03, Robert Webb wrote:
> I took the OP's request as for doing QoS at the edge of their network
> and not necessarily the entire path.

Indeed, but even then, you could be handing off the traffic to a
downstream customer, and can't guarantee what they do to those ToS fields.


>
> As another person stated, the real answer is to add more bandwidth if
> you are having to QoS to Office365 because it is affecting other
> internet based services.

Yes and no.

More bandwidth never hurt anyone, but packet loss in the remote network
toward the cloud will hurt you.

Mark.

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Jay R. Ashworth]

- Original Message -
> From: "Sean Donelan" 

> I don't think SHAKEN/STIR really addresses the root problems with
> spoofing phone numbers, anymore than any of the BGP proposals for spoofing
> IP addresses.
> 
> Nevertheless, the FCC wants to be seen as doing something.  So Chairman
> Pai is having a summit to show all the progress.
> 
> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
> focused on the industry’s implementation of SHAKEN/STIR, a caller ID
> authentication framework to combat illegal robocalls and caller ID
> spoofing.  Chairman Pai expects major voice service providers to deploy
> the SHAKEN/STIR framework this year.   The summit will showcase the
> progress that major providers have made toward reaching that goal and
> provide an opportunity to identify any challenges to implementation and
> how best to overcome them.

Well, y'know, it's been 10 years since I originated calls to LD carriers.

But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
that weren't for 10D calling numbers *they had assigned us* (and hence I 
had to work that out with them to prove that *someone* had)...

nd the other 2 didn't give a crap.  I could send them anything -- even calls
with CNID that wasn't a valid NANP address (4th digit 1, frex).

Since nearly all of this is being originated over PRIs to LD carriers, right;
maybe if the FCC just threatened the LD carriers who do not do the calling
number legitimacy enforcement the regs (I think) already require them to do...?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Must have ISP Open Source & tools

[Alexander Lyamin]

I would chime in with tools for network analysis and planning:

http://bgp.he.net/
http://isolario.it
http://radar.qrator.net

last one is something we work on as a community project.

On Mon, Jul 8, 2019 at 2:07 AM Mehmet Akcin  wrote:

> Hey there
>
> We are a growing ISP in Colombia and Latin America. I am interested in
> hearing from others regarding tools and software they recommend we must
> have such as LibreNMS, Rancid etc.
>
> It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-)
>
> Hope this thread is useful others too!
>
> Mehmet
> --
> Mehmet
> +1-424-298-1903
>


-- 

Alexander Lyamin, VP & Founder

 Qrator * Labs CZ *

office: +420 602 558 144 <++420+602+558+144>

mob: +420 774 303 807 <++420+774+303+807>
skype: melanor9

mailto:  l...@qrator.net

SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Sean Donelan]

I don't think SHAKEN/STIR really addresses the root problems with 
spoofing phone numbers, anymore than any of the BGP proposals for spoofing 
IP addresses.


Nevertheless, the FCC wants to be seen as doing something.  So Chairman 
Pai is having a summit to show all the progress.


On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit 
focused on the industry’s implementation of SHAKEN/STIR, a caller ID 
authentication framework to combat illegal robocalls and caller ID 
spoofing.  Chairman Pai expects major voice service providers to deploy 
the SHAKEN/STIR framework this year.   The summit will showcase the 
progress that major providers have made toward reaching that goal and 
provide an opportunity to identify any challenges to implementation and 
how best to overcome them.



https://www.fcc.gov/SHAKENSTIRSummit

Date: Thursday, July 11, 2019
Time: Unknown, the public announcement did not include the time. Usually 
these summits start around 9am EDT.
Location: Commission Meeting Room at FCC Headquarters, 445 12th Street, 
S.W. Washington, D.C. 20554.


It will also be streamed at the FCC’s web page at www.fcc.gov/live.

RE: QoS for Office365

[adamv0025]

> Warren Kumari
> Sent: Monday, July 8, 2019 8:06 PM
> 
> On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka  wrote:
> >
> >
> >
> > On 8/Jul/19 20:50, Warren Kumari wrote:
> >
> > > Depends -- I'd note that the OP said "How can we mark the trafic
> > > while keeping the security..." -- some people use the COS / DSCP
> > > bits to annotate packets with security information, and use that to
> > > make *security decisions* instead of using it to prioritize traffic.
> > > Now, I'm not saying that this is why the OP is asking (or that I
> > > think it is a good idea, because, well,  I don't think it is!), but
> > > it *is* a practice worth knowing about.
> >
> > Assuming we are discussing such packets traversing the public
> > Internet, a little tricky to expect IPP/DSCP values to remain intact
> > in the life of an Internet packet.
> 
> Goodness no -- I've only ever seen this done within a single network
> (including inside some tunnels); expecting this to work across the Big I-
> internet is crazypants time. I personally think that the idea itself is 
> stupid,
> but, well, their network, their rules, and it "works" for them.
> 
And yet the SD-WAN promising MPLS experience over the internet and other BS 
sells like crazy ;)

adam

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka  wrote:
>
>
>
> On 8/Jul/19 20:50, Warren Kumari wrote:
>
> > Depends -- I'd note that the OP said "How can we mark the trafic while
> > keeping the security..." -- some people use the COS / DSCP bits to
> > annotate packets with security information, and use that to make
> > *security decisions* instead of using it to prioritize traffic. Now,
> > I'm not saying that this is why the OP is asking (or that I think it
> > is a good idea, because, well,  I don't think it is!), but it *is* a
> > practice worth knowing about.
>
> Assuming we are discussing such packets traversing the public Internet,
> a little tricky to expect IPP/DSCP values to remain intact in the life
> of an Internet packet.

Goodness no -- I've only ever seen this done within a single network
(including inside some tunnels); expecting this to work across the Big
I-internet is crazypants time. I personally think that the idea itself
is stupid, but, well, their network, their rules, and it "works" for
them.

W

>
> Mark.



-- 
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: QoS for Office365

[Robert Webb]

I took the OP's request as for doing QoS at the edge of their network and
not necessarily the entire path.

As another person stated, the real answer is to add more bandwidth if you
are having to QoS to Office365 because it is affecting other internet based
services.

Robert

On Mon, Jul 8, 2019 at 3:00 PM Mark Tinka  wrote:

>
>
> On 8/Jul/19 20:50, Warren Kumari wrote:
>
> > Depends -- I'd note that the OP said "How can we mark the trafic while
> > keeping the security..." -- some people use the COS / DSCP bits to
> > annotate packets with security information, and use that to make
> > *security decisions* instead of using it to prioritize traffic. Now,
> > I'm not saying that this is why the OP is asking (or that I think it
> > is a good idea, because, well,  I don't think it is!), but it *is* a
> > practice worth knowing about.
>
> Assuming we are discussing such packets traversing the public Internet,
> a little tricky to expect IPP/DSCP values to remain intact in the life
> of an Internet packet.
>
> Mark.
>

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 20:50, Warren Kumari wrote:

> Depends -- I'd note that the OP said "How can we mark the trafic while
> keeping the security..." -- some people use the COS / DSCP bits to
> annotate packets with security information, and use that to make
> *security decisions* instead of using it to prioritize traffic. Now,
> I'm not saying that this is why the OP is asking (or that I think it
> is a good idea, because, well,  I don't think it is!), but it *is* a
> practice worth knowing about.

Assuming we are discussing such packets traversing the public Internet,
a little tricky to expect IPP/DSCP values to remain intact in the life
of an Internet packet.

Mark.

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 12:31 PM Jared Mauch  wrote:
>
>
>
> > On Jul 2, 2019, at 5:18 PM, Joe Yabuki  wrote:
> >
> > Hi all,
> >
> > How do you deal with QoS for Office365, since the IPs are subject to 
> > changes ?
> >
> > How can we mark the trafic while keeping the security (I fear the marking 
> > based on TCP/UDP Ports since they are not without an additional risk coming 
> > from worms/virus using those ports for example, and doing that directly on 
> > the PCs doesn't seem to be the best solution) ?
>
>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.

Depends -- I'd note that the OP said "How can we mark the trafic while
keeping the security..." -- some people use the COS / DSCP bits to
annotate packets with security information, and use that to make
*security decisions* instead of using it to prioritize traffic. Now,
I'm not saying that this is why the OP is asking (or that I think it
is a good idea, because, well,  I don't think it is!), but it *is* a
practice worth knowing about.

One enterprise I've seen does:
firewall {
family inet {
   filter Egress {
term allow {
from {
prefix-list {
TrustedSubnets;
}
dscp af42;
}
then accept;
}
term default {
then {
encapsulate CaptiveGarden;
}
}
}
  }
}

They have some shim thingie on corporate machines which tags
"approved" traffic with AF42 (and also mark on switches from other
devices which should have Internet access), and everyone else gets
bumped to a captive portal / logging / scrubbing firewall thingie.
This is remarkably bletcherous, but (because?) you can do 'iptables -t
mangle -A FORWARD -j dscp --set-dscp-class  AF42' to tag all
packets...

W

>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.
>
> - Jared



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

NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community,

The NANOG Program Committee (PC) is excited to announce that we are now
accepting proposals for all sessions at NANOG 77 in Austin, Texas, October
28-30, 2019. Below is a summary of key details and dates from the Call For
Presentations on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Given by many of the industry’s top minds, presentations at NANOG meetings
are meant to spark the imagination, encourage dialog, and drive new
solutions to our greatest networking challenges. The PC is currently
seeking proposals, and also welcomes suggestions for speakers and topics.
Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Timeline for submission and proposal review:

   -

   Submitter enters abstract (and draft slides if possible) in PC Tool
   prior to the deadline for slide submission.
   -

   PC performs initial review and assigns a “shepherd” to help develop the
   submission — within 2 weeks.
   -

   Submitter develops draft slides of talk if not already submitted with
   the initial proposal. Please submit initial draft slides early — the PC
   does not evaluate submissions until draft slides are available for review.
   NANOG Staff is available to assist with slide templates upon request from
   the submitter.
   -

   Panel and Track submissions should provide a topic list and
   intended/confirmed participants in the abstract.
   -

   PC reviews the slides and continues to work with Submitter as needed to
   develop the topic.
   -

   Draft presentation slides should be submitted prior to the published
   deadline for slides (Aug. 19, 2019).
   -

   PC evaluates submissions to determine presentations for the agenda
   (posted on Sep 30, 2019).
   -

   Agenda assembled and posted.
   -

   Submitters notified.
   -

   Final presentation slides must be submitted prior to the published
   deadline for slides (Oct. 21, 2019).


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the PC (
nano...@nanog.org), and a representative will respond to you in a timely
manner. Otherwise, submit your talk, keynote, track, or panel proposal to
the PC Tool at your earliest convenience. We look forward to reviewing your
submission!

Key dates for NANOG 77:

Date

Event/Deadline

Jul. 1, 2019

CFP Opens & Agenda Outline Posted, Early Registration Begins

Jul. 22, 2019

Standard Registration Begins

Aug. 19, 2019

CFP Deadline: Presentation Slides Due

Sep. 23, 2019

CFP Topic List & NANOG Meeting HIghlights Page posted, Late Registration
Begins

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins

Final slides must be submitted by Monday, October 21, 2019, and no changes
will be accepted between that date and the conference. Materials received
after that date may be updated on the website after the completion of the
conference.

We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC

[NANOG-announce] NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community,

The NANOG Program Committee (PC) is excited to announce that we are now
accepting proposals for all sessions at NANOG 77 in Austin, Texas, October
28-30, 2019. Below is a summary of key details and dates from the Call For
Presentations on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Given by many of the industry’s top minds, presentations at NANOG meetings
are meant to spark the imagination, encourage dialog, and drive new
solutions to our greatest networking challenges. The PC is currently
seeking proposals, and also welcomes suggestions for speakers and topics.
Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Timeline for submission and proposal review:

   -

   Submitter enters abstract (and draft slides if possible) in PC Tool
   prior to the deadline for slide submission.
   -

   PC performs initial review and assigns a “shepherd” to help develop the
   submission — within 2 weeks.
   -

   Submitter develops draft slides of talk if not already submitted with
   the initial proposal. Please submit initial draft slides early — the PC
   does not evaluate submissions until draft slides are available for review.
   NANOG Staff is available to assist with slide templates upon request from
   the submitter.
   -

   Panel and Track submissions should provide a topic list and
   intended/confirmed participants in the abstract.
   -

   PC reviews the slides and continues to work with Submitter as needed to
   develop the topic.
   -

   Draft presentation slides should be submitted prior to the published
   deadline for slides (Aug. 19, 2019).
   -

   PC evaluates submissions to determine presentations for the agenda
   (posted on Sep 30, 2019).
   -

   Agenda assembled and posted.
   -

   Submitters notified.
   -

   Final presentation slides must be submitted prior to the published
   deadline for slides (Oct. 21, 2019).


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the PC (
nano...@nanog.org), and a representative will respond to you in a timely
manner. Otherwise, submit your talk, keynote, track, or panel proposal to
the PC Tool at your earliest convenience. We look forward to reviewing your
submission!

Key dates for NANOG 77:

Date

Event/Deadline

Jul. 1, 2019

CFP Opens & Agenda Outline Posted, Early Registration Begins

Jul. 22, 2019

Standard Registration Begins

Aug. 19, 2019

CFP Deadline: Presentation Slides Due

Sep. 23, 2019

CFP Topic List & NANOG Meeting HIghlights Page posted, Late Registration
Begins

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins

Final slides must be submitted by Monday, October 21, 2019, and no changes
will be accepted between that date and the conference. Materials received
after that date may be updated on the website after the completion of the
conference.

We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Level3/CenturyLink IRR Contact

[Steve Saner]

On 7/8/19 12:14 PM, Matt Harris wrote:
On Mon, Jul 8, 2019 at 11:20 AM Joe Nelson > wrote:


Does anyone know who to contact to have old information removed from
Level3/CenturyLink's IRR.  My ASN still shows in their registry with
stale information from an old customer of theirs but I can't seem to
find anyone at CenturyLink that even knows what an IRR is so I'm
just going in circles.  I'd like to just have the stale info removed
so when I add my info to Merit, there isn't a conflict.

Thanks,

Joe



I had the same issue show up with a netblock that we used to route for a 
customer. That netblock has now been allocated to someone else and they 
contacted me to see if we could get it removed from the IRR as it was 
causing them some trouble.


I still have a circuit with Level3/CenturyLink, so I ended up opening a 
trouble ticket through the customer portal on that circuit and explained 
my need.


I got a response back that it had been removed from the BGP filters, so 
I had to explain that while that's find and good, I'm really needing it 
removed from the IRR.


The response back after that was that it isn't in the IRR. I wrote back 
showing that it in fact was in the IRR.


After a couple days of no response I commented the ticket again asking 
for the issue to be escalated. Finally got a response back that it had 
been removed.


Took about a week total.

Steve

--
--
Steven Saner   Voice:  316-858-3000
Director of Network Operations  Fax:  316-858-3001
Hubris Communicationshttp://www.hubris.net

Re: Level3/CenturyLink IRR Contact

[Matt Harris]

On Mon, Jul 8, 2019 at 11:20 AM Joe Nelson  wrote:

> Does anyone know who to contact to have old information removed from
> Level3/CenturyLink's IRR.  My ASN still shows in their registry with stale
> information from an old customer of theirs but I can't seem to find anyone
> at CenturyLink that even knows what an IRR is so I'm just going in
> circles.  I'd like to just have the stale info removed so when I add my
> info to Merit, there isn't a conflict.
>
> Thanks,
>
> Joe
>

Same issue here. Was never able to get anyone to correct it after trying a
solid handful of email contacts there.

What's weird is that the entry was created while I owned the space and was
created by a large enough organization that I'm not sure it's fraud (plus
they've never tried announcing the space that I've seen) but I don't see
how it'd have been a typo based on the space they are announcing, so I'm
not sure exactly what the people involved were thinking. My IPv6 /32 is in
the Level3 IRR db though, with an origin set to AS22773 which is an
organization I've never had any relationship with whatsoever.

Good luck!

Re: DNSSEC implementation for Office365

[Tristan Hoar]

Hi Joe,

outlook.com is unsigned so I doubt they support it.
[trishoar@rhel8 ~]$ delv outlook.com
; unsigned answer
outlook.com.300 IN  A   40.97.161.50
outlook.com.300 IN  A   40.97.128.194
outlook.com.300 IN  A   40.97.116.82
outlook.com.300 IN  A   40.97.160.2
outlook.com.300 IN  A   40.97.148.226
outlook.com.300 IN  A   40.97.153.146
outlook.com.300 IN  A   40.97.164.146
outlook.com.300 IN  A   40.97.156.114


Tris


On Wed, 2019-07-03 at 10:36 +0200, Joe Yabuki wrote:
> Hi,
> 
> Please is anyone aware of DNSSEC implementation for Office365 ? This
> information seems to be hard to get from Microsoft... and it's hard
> for me to think that they don't support it.
> 
> Thanks,
> Joe
> *
> This message has been checked for viruses by the 
> Birmingham Grid for Learning.  For guidance on good 
> e-mail practice, e-mail viruses and hoaxes please visit:
> http://www.bgfl.org/emailaup
> *
> 


signature.asc
Description: This is a digitally signed message part

Spoofer Report for NANOG for Jun 2019

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Jun 2019:
   ASN Name   Fixed-By
  7849 CROCKERCOM 2019-06-06
 19230 NANOG  2019-06-08
 11427 SCRR-11427 2019-06-26

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Jun 2019:
   ASN Name   First-Spoofed Last-Spoofed
  6939 HURRICANE 2016-02-22   2019-06-29
   209 CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2019-06-26
  6128 CABLE-NET-1   2016-09-03   2019-06-06
 27364 ACS-INTERNET  2016-09-27   2019-06-28
 20412 CLARITY-TELECOM   2016-09-30   2019-06-24
 20001 ROADRUNNER-WEST   2016-10-08   2019-06-25
  6181 FUSE-NET  2016-10-10   2019-06-28
 25787 ROWE-NETWORKS 2016-10-21   2019-06-29
   174 COGENT-1742016-10-21   2019-06-28
 30341 SCTA-ASN  2016-10-31   2019-06-18
 32440 LONI  2016-11-03   2019-06-25
 12083 WOW-INTERNET  2016-11-09   2019-06-30
 13427 SOFTCOM-INTERNET-COMMUNICATION2016-11-14   2019-06-26
 21832 KELLINCOM-1   2017-02-03   2019-06-26
 18451 LESNET2017-02-22   2019-06-26
  6327 SHAW  2017-03-24   2019-06-16
   852 ASN8522017-04-16   2019-06-18
 19624 SERVERROOM2017-06-02   2019-06-06
   701 UUNET 2017-06-14   2019-06-04
 63296 AMARILLO-WIRELESS 2017-09-01   2019-06-27
   546 PARSONS-PGS-1 2017-11-20   2019-06-17
  4201 ORST  2018-04-19   2019-06-26
   225 VIRGINIA  2018-06-18   2019-06-20
 33509 CASCADE-ACCESS-LLC-CA-ESTOR1  2018-06-22   2019-06-27
 33452 RW2018-09-19   2019-06-29
 20448 VPNTRANET-LLC 2018-09-20   2019-06-26
 63275 RADIOWIRE 2019-02-07   2019-06-11
  8047 GCI   2019-04-11   2019-06-26
 10745 ARIN-ASH-CHA  2019-04-29   2019-06-25
  6058 NORTHWESTEL-INC   2019-05-06   2019-06-25
138576   2019-05-21   2019-06-29
  6428 CDM   2019-06-04   2019-06-04
 19751 CCRTC 2019-06-06   2019-06-25
 33387 DATASHACK 2019-06-06   2019-06-28
 21804 ACCESS-SK 2019-06-09   2019-06-11
 16787 CHARTER-16787 2019-06-17   2019-06-17

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 18:18, Jared Mauch wrote:

>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.
>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.

In some cases, the motivation for these requirements is fueled by trying
to outsmart your competitors.

I just don't know of a reliable, contractual way that you can use QoS to
say your DIA or IP Transit service is better than that of your competitor.

Mark.

Re: CDN question

[William Herrin]

On Mon, Jul 8, 2019 at 9:22 AM Tim Wilson 
wrote:
> What is the advantages and disadvantages of building your own CDN
(mainly, in USA, Brazil and Australia)? We are running a website and using
CDNs for a while to delivery static content. Few guys brought this question
for a tech review. And I'm curious of opinion of people who maybe did that.

Hi Tim,

If by some miracle you manage to hire the technical experts needed to build
a CDN that works, you'll find they get frustrated and quit over the
whack-a-mole system balancing activity needed to operate a CDN. Unless you
want to be in the CDN business itself, your best bet is to rent space on
someone else's CDN.

The secondary bonus of someone else's CDN is that you don't have much of a
sunk cost, so if they have trouble keeping it working you can readily
switch to a different company's CDN. This allows you to keep your eyes on
the prize: the business your company is actually in.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: QoS for Office365

[Mark Tinka]

On 2/Jul/19 23:18, Joe Yabuki wrote:

> Hi all, 
>
> How do you deal with QoS for Office365, since the IPs are subject to
> changes ?
>
> How can we mark the trafic while keeping the security (I fear the
> marking based on TCP/UDP Ports since they are not without an
> additional risk coming from worms/virus using those ports for example,
> and doing that directly on the PCs doesn't seem to be the best solution) ?

Funny, I was just answering an internal question about this, last week.

As with all things Internet, my stance is if you don't have end-to-end
control, trying to do QoS is pointless.

That said, I believe it should be possible to apply some kind of
meaningful, end-to-end QoS together with Microsoft if you took up one of
their Express Route services, given that is considered a private,
premium service.

Mark.

Re: Level3/CenturyLink IRR Contact

[Job Snijders]

I will ping you off list with contact details.

Kind regards,

Job

On Mon, Jul 8, 2019 at 6:20 PM Joe Nelson  wrote:
>
> Does anyone know who to contact to have old information removed from 
> Level3/CenturyLink's IRR.  My ASN still shows in their registry with stale 
> information from an old customer of theirs but I can't seem to find anyone at 
> CenturyLink that even knows what an IRR is so I'm just going in circles.  I'd 
> like to just have the stale info removed so when I add my info to Merit, 
> there isn't a conflict.
>
> Thanks,
>
> Joe

Re: QoS for Office365

[Jared Mauch]

> On Jul 2, 2019, at 5:18 PM, Joe Yabuki  wrote:
> 
> Hi all, 
> 
> How do you deal with QoS for Office365, since the IPs are subject to changes ?
> 
> How can we mark the trafic while keeping the security (I fear the marking 
> based on TCP/UDP Ports since they are not without an additional risk coming 
> from worms/virus using those ports for example, and doing that directly on 
> the PCs doesn't seem to be the best solution) ?


Add bandwidth?

QoS is a great tool when you’re constrained and must classify your critical 
traffic, but it’s not a substitute of getting enough capacity to offices.

I have only applied QoS to voice traffic to ensure it gets through, the rest 
you need to budget for the bandwidth needs of the site.  The price of bandwidth 
likely isn’t insane in your market, but your budget may be.. I’ve found that 
most places won’t quote you a service for less than $1500 USD MRC.  I know you 
can get the incumbents to often deliver 1G service for $2k/mo in the US (and 
possibly cheaper).

I’ve found a lot of people are still stuck in TDM mentality instead of just 
getting a 1G/10G service.

- Jared

Re: [EXTERNAL] Re: Microsoft SNDS contact

[Udeme Ukutt]

Ah, oops.

On Wed, Jul 3, 2019 at 10:46 AM Brian Rak  wrote:

> Yea, that's the email we've been using (that's trying to tell us to just
> split it into /24s)
> On 7/3/2019 10:27 AM, Udeme Ukutt wrote:
>
> Hey Brian - try msn-s...@microsoft.com. IIRC that's more geared towards
> JMRP, but I think there's a chance.
>
> Udeme
> Postmaster at Wish
>
> On Wed, Jul 3, 2019 at 10:14 AM Brian Rak  wrote:
>
>>
>> On 7/3/2019 10:09 AM, Hansen, Christoffer wrote:
>> > On 03/07/2019 15:50, Hansen, Christoffer wrote:
>> >> https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx
>> > E.g. with asn 20473. Key that in. I can select the address fetched from
>> > a background WHOIS lookup by MS Smart Network Data Service. For the
>> > confirmation email to be sent to.
>> >
>>
>> We've tried this approach in the past, but it ends up dragging in a lot
>> of IP space that we're announcing on behalf of customers. This is less
>> then ideal, as then we either have to go back and manually remove all
>> the customer owned IP space, or deal with a bunch of noise from it.
>> We'd be willing to accept that as a solution if it were a one-off thing,
>> but it's a lot of extra work to do every time we acquire more IP space.
>>
>>

Re: [EXTERNAL] Re: Microsoft SNDS contact

[Udeme Ukutt]

Hey Brian - try msn-s...@microsoft.com. IIRC that's more geared towards
JMRP, but I think there's a chance.

Udeme
Postmaster at Wish

On Wed, Jul 3, 2019 at 10:14 AM Brian Rak  wrote:

>
> On 7/3/2019 10:09 AM, Hansen, Christoffer wrote:
> > On 03/07/2019 15:50, Hansen, Christoffer wrote:
> >> https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx
> > E.g. with asn 20473. Key that in. I can select the address fetched from
> > a background WHOIS lookup by MS Smart Network Data Service. For the
> > confirmation email to be sent to.
> >
>
> We've tried this approach in the past, but it ends up dragging in a lot
> of IP space that we're announcing on behalf of customers. This is less
> then ideal, as then we either have to go back and manually remove all
> the customer owned IP space, or deal with a bunch of noise from it.
> We'd be willing to accept that as a solution if it were a one-off thing,
> but it's a lot of extra work to do every time we acquire more IP space.
>
>

CDN question

[Tim Wilson]

Hi, folks,

I have a question to you as experienced auditory.

What is the advantages and disadvantages of building your own CDN (mainly,
in USA, Brazil and Australia)? We are running a website and using CDNs for
a while to delivery static content. Few guys brought this question for a
tech review. And I'm curious of opinion of people who maybe did that.

So far one of the bit advantages I see is distribution of authoritative
DNS. But it is a bit too low for building and running CDN.

Will appreciate any opinion shared privately or on this list.

Thanks.

Tim

Level3/CenturyLink IRR Contact

[Joe Nelson]

Does anyone know who to contact to have old information removed from
Level3/CenturyLink's IRR.  My ASN still shows in their registry with stale
information from an old customer of theirs but I can't seem to find anyone
at CenturyLink that even knows what an IRR is so I'm just going in
circles.  I'd like to just have the stale info removed so when I add my
info to Merit, there isn't a conflict.

Thanks,

Joe

DNSSEC implementation for Office365

[Joe Yabuki]

Hi,

Please is anyone aware of DNSSEC implementation for Office365 ? This
information seems to be hard to get from Microsoft... and it's hard for me
to think that they don't support it.

Thanks,
Joe

QoS for Office365

[Joe Yabuki]

Hi all,

How do you deal with QoS for Office365, since the IPs are subject to
changes ?

How can we mark the trafic while keeping the security (I fear the marking
based on TCP/UDP Ports since they are not without an additional risk coming
from worms/virus using those ports for example, and doing that directly on
the PCs doesn't seem to be the best solution) ?

Many thanks,
Joe

RE: Must have ISP Open Source & tools

[Ryan Hamel]

Java as a dependency this day and age…

-Ryan

From: Jason Kuehl 
Sent: Monday, July 08, 2019 6:41 AM
To: Mehmet Akcin 
Cc: Ryan Hamel ; Niels Bakker 
; nanog@nanog.org
Subject: Re: Must have ISP Open Source & tools

We use https://cbackup.me/en/ over Rancid

--
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Must have ISP Open Source & tools

[Nico CARTRON]

On 08-Jul-2019 15:49 CEST,  wrote:

> On 7/7/19 8:42 PM, Ryan Hamel wrote:
> > Telegraf + InfluxDB = Tons of Grafana Dashboards
> 
> This handles time-series data really, really well and also pairs quite well
> with the ELK stack (Elasticsearch + Logstash + Kibana) for event-oriented
> data.  Kibana can talk to InfluxDB, and Grafana can talk to Elasticsearch to
> somewhat tie things together, but they each are of course focused on their
> own type of data.
> 
> In particular, Logstash is a great place to send your syslog streams from
> all your gear toward.

The Grafana guys have launched Loki
(https://github.com/grafana/loki#loki-like-prometheus-but-for-logs), which is
"Prometheus for logs".

-- 
Nico

Re: Must have ISP Open Source & tools

[Brandon Martin]

On 7/7/19 8:42 PM, Ryan Hamel wrote:

Telegraf + InfluxDB = Tons of Grafana Dashboards


This handles time-series data really, really well and also pairs quite 
well with the ELK stack (Elasticsearch + Logstash + Kibana) for 
event-oriented data.  Kibana can talk to InfluxDB, and Grafana can talk 
to Elasticsearch to somewhat tie things together, but they each are of 
course focused on their own type of data.


In particular, Logstash is a great place to send your syslog streams 
from all your gear toward.

--
Brandon Martin

Re: Must have ISP Open Source & tools

[Jason Kuehl]

We use https://cbackup.me/en/ over Rancid

On Sun, Jul 7, 2019 at 11:38 PM Mehmet Akcin  wrote:

> Awesome list
>
> On Sun, Jul 7, 2019 at 19:42 Ryan Hamel  wrote:
>
>> My List:
>>
>> Oxidized as a replacement for RANCID
>> Telegraf + InfluxDB = Tons of Grafana Dashboards
>> (Open Source Slack Alternative)
>> Ansible or Python Knowledge with Paramiko or netmiko for network
>> automation.
>>
>> BGP:
>>
>> FRRouting - Mimics Cisco CLI
>> BIRD - Programming style config format.
>> Exabgp - Mostly used for API driven applications, monitoring with
>> heartbeat scripts.
>> (many others)
>>
>> DDoS detection and/or filtering:
>>
>> Fastnetmon - Supports many methods for packet processing.
>> Ddosdetector (IPv4 Only) - Uses netmap for packet processing.
>>
>> Top Talkers + Other Creativeness (like fib compressing, or route
>> optimization):
>>
>> pmacct - sflow/netflow combined with BGP, and a database backend
>>
>> Servers:
>>
>> Sensu or LibreNMS for Nagios type monitoring.
>>
>> Diagnostics:
>>
>> MTR - ...and knowing how to interpret it's output.
>>
>> -Ryan
>>
>> --
> Mehmet
> +1-424-298-1903
>


-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com