Re: Orange : Propagating Bogus Saudi Telecom Announcement

[Tom Beecher]

Maybe. Would be for someone at Zayo to comment on.

Looks like 39386 has been ( and still is )  announcing the NY9 prefix since
early June. ( Fix your filters, please. )

Not sure if Zayo is having an issue by which they would have started using
the route via ST all of a sudden. In any event, Orange said they're not
passing it along anymore.


On Mon, Aug 24, 2020 at 4:04 PM Richard Porter 
wrote:

> https://twitter.com/millionaire_xrp/status/1297952306357567488?s=10
>
> Related? reports of outages at Chase?
>
> On Mon, Aug 24, 2020 at 2:13 PM Tom Beecher  wrote:
>
>> Saudi Telecom ( AS 39386 ) is currently announcing Equinix NY9's IX
>> prefix, and Orange is gladly sharing that for the world to see.
>>
>> Zayo : You might want to not be using that either when you're directly
>> connected to that exchange. :)
>>
>> *Router:* New York, NY
>> *Command:* show route protocol bgp table inet.0 198.32.118.0/24 terse
>> exact
>>
>>
>> inet.0: 833301 destinations, 5821043 routes (833250 active, 16 holddown, 88 
>> hidden)
>> + = Active Route, - = Last Active, * = Both
>> A V DestinationP Prf   Metric 1   Metric 2  Next hopAS path
>> * ? 198.32.118.0/24B 170100 4294967294  5511 
>> 39386 39386 39386 39386 I
>>   unverified   >64.125.29.222
>> 64.125.29.220
>>   ?B 170100 4294967294  5511 
>> 39386 39386 39386 39386 I
>>   unverified   >64.125.29.222
>> 64.125.29.220
>>   ?B 170100 4294967294  5511 
>> 39386 39386 39386 39386 I
>>   unverified   >64.125.29.220
>> 64.125.29.222
>>   ?B 170100 4294967294  5511 
>> 39386 39386 39386 39386 I
>>   unverified   >64.125.29.220
>> 64.125.29.222
>>   ?B 170100 4294967294  5511 
>> 39386 39386 39386 39386 I
>>   unverified   >64.125.29.220
>> 64.125.29.222
>> {master}
>>
>>

Re: Orange : Propagating Bogus Saudi Telecom Announcement

[Richard Porter]

https://twitter.com/millionaire_xrp/status/1297952306357567488?s=10

Related? reports of outages at Chase?

On Mon, Aug 24, 2020 at 2:13 PM Tom Beecher  wrote:

> Saudi Telecom ( AS 39386 ) is currently announcing Equinix NY9's IX
> prefix, and Orange is gladly sharing that for the world to see.
>
> Zayo : You might want to not be using that either when you're directly
> connected to that exchange. :)
>
> *Router:* New York, NY
> *Command:* show route protocol bgp table inet.0 198.32.118.0/24 terse
> exact
>
>
> inet.0: 833301 destinations, 5821043 routes (833250 active, 16 holddown, 88 
> hidden)
> + = Active Route, - = Last Active, * = Both
> A V DestinationP Prf   Metric 1   Metric 2  Next hopAS path
> * ? 198.32.118.0/24B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.222
> 64.125.29.220
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.222
> 64.125.29.220
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
> {master}
>
>

Re: Orange : Propagating Bogus Saudi Telecom Announcement

[John Von Essen]

Nice find Tom…


> On Aug 24, 2020, at 3:11 PM, Tom Beecher  wrote:
> 
> Saudi Telecom ( AS 39386 ) is currently announcing Equinix NY9's IX prefix, 
> and Orange is gladly sharing that for the world to see. 
> 
> Zayo : You might want to not be using that either when you're directly 
> connected to that exchange. :)
> 
> Router: New York, NY
> Command: show route protocol bgp table inet.0 198.32.118.0/24 
>  terse exact
> 
> 
> inet.0: 833301 destinations, 5821043 routes (833250 active, 16 holddown, 88 
> hidden)
> + = Active Route, - = Last Active, * = Both
> A V DestinationP Prf   Metric 1   Metric 2  Next hopAS path
> * ? 198.32.118.0/24 B 170100 4294967294   
>5511 39386 39386 39386 39386 I
>   unverified   >64.125.29.222
> 64.125.29.220
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.222
> 64.125.29.220
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
>   ?B 170100 4294967294  5511 
> 39386 39386 39386 39386 I
>   unverified   >64.125.29.220
> 64.125.29.222
> {master}



smime.p7s
Description: S/MIME cryptographic signature

Orange : Propagating Bogus Saudi Telecom Announcement

[Tom Beecher]

Saudi Telecom ( AS 39386 ) is currently announcing Equinix NY9's IX prefix,
and Orange is gladly sharing that for the world to see.

Zayo : You might want to not be using that either when you're directly
connected to that exchange. :)

*Router:* New York, NY
*Command:* show route protocol bgp table inet.0 198.32.118.0/24 terse exact


inet.0: 833301 destinations, 5821043 routes (833250 active, 16
holddown, 88 hidden)
+ = Active Route, - = Last Active, * = Both
A V DestinationP Prf   Metric 1   Metric 2  Next hopAS path
* ? 198.32.118.0/24B 170100 4294967294
5511 39386 39386 39386 39386 I
  unverified   >64.125.29.222
64.125.29.220
  ?B 170100 4294967294
5511 39386 39386 39386 39386 I
  unverified   >64.125.29.222
64.125.29.220
  ?B 170100 4294967294
5511 39386 39386 39386 39386 I
  unverified   >64.125.29.220
64.125.29.222
  ?B 170100 4294967294
5511 39386 39386 39386 39386 I
  unverified   >64.125.29.220
64.125.29.222
  ?B 170100 4294967294
5511 39386 39386 39386 39386 I
  unverified   >64.125.29.220
64.125.29.222
{master}

Re: Mail rejected at secureserver.net/godaddy any contacts over there?

[Miles Fidelman]

I've found that GoDaddy tech support is amazingly good, and responsive.  
If you're a customer, of course (and it's kind of hard not to be these 
days).  Maybe just call their 800 number.


Miles Fidelman

On 8/24/20 12:57 PM, Drew Weaver wrote:


I’ve attempted to contact them using their form but I feel as though I 
am stuck in a loop with their diligent and no doubt hard working staff 
they have manning that post.


Can anyone put me into contact with someone that can answer a few 
questions?


Thanks,

-Drew


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Mail rejected at secureserver.net/godaddy any contacts over there?

[Drew Weaver]

I've attempted to contact them using their form but I feel as though I am stuck 
in a loop with their diligent and no doubt hard working staff they have manning 
that post.

Can anyone put me into contact with someone that can answer a few questions?

Thanks,
-Drew

Get ready to hack!

[NANOG News]

Join many of the brightest minds in our community at the NANOG 80 Virtual
Hackathon. Our first all-virtual hackathon kicks off Saturday, October 17
at 1:00 pm EDT — the weekend before the NANOG 80
 conference. As always,
participation is free, and open to all who register.

Get all the details about the format, schedule, and more! And if you'd like
to participate but aren’t sure where to start, we have lots of topic ideas
to share. Please reach out to us: hackathon-supp...@nanog.org.

Learn More + Register Now

Re: Ipv6 help

[JORDI PALET MARTINEZ via NANOG]

You probably mean 464XLAT 

Ask you vendors. They should support it. Ask for RFC8585 support, even better.

If they don't do, is because they are interested only in selling new boxes ... 
just something to think in the future about those vendors.

I can tell you that many vendors now support or are waiting for some customers 
to ask for it, the CLAT. I've been doing this for many customers. Sometimes, 
they only do under request, same as many other firmware features.

Regards,
Jordi
@jordipalet
 
 

El 24/8/20 16:32, "NANOG en nombre de Roman Tatarnikov" 
 escribió:

I've been looking into implementing 646XLAT, however I found the problem 
ends up with clients' routers.

When you give them Ethernet cable that has internet on it, whatever it gets 
plugged into must support CLAT in order for 646XLAT to work. I was not able to 
find any small devices that support it natively, at least according to their 
description. The only way I found to enable CLAT support is to flash those 
devices with OpenWRT, which is not really an option when you are giving away 
those tiny boxes to residential clients when they sign up with you.

So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell 
me which device works with 646XLAT out of the box. And hopefully it's something 
TRENDnet's.

-- 
Roman V Tatarnikov
https://linkedin.com/in/rtatarnikov
W: 310 929 2607 | C: 805 746 2886



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: 00:aa:bb:01:23:45

[Tom Hill]

On 20/08/2020 09:53, Baldur Norddahl wrote:
> 
> By accident I noticed several of my VPLS instances have
> 00:aa:bb:01:23:45 in the MAC table. We never sent anything just received
> a little traffic from that. Obviously not a real MAC address so I tried
> to search Google for it. I find several hits with apparently ADSL users
> doing pppd (which we do not have).
> 
> Anyone have any idea what this could be?

I do not - but I would isolate the port(s) it's coming from, and pick on
your favourite customer out of the bunch & simply ask them what they
have connected. Given that anyone can pick their own MAC addresses/spoof
MAC addresses, the fastest resolution to this mystery will likely be to
just ask.

Let us know what you find out! :)

-- 
Tom

Re: ROA coverage info

[Rayhaan Jaufeerally (NANOG)]

There's also this site run by NIST: https://rpki-monitor.antd.nist.gov/ which
contains further breakdowns

On Mon, Aug 24, 2020 at 4:46 PM Nathalie Trenaman  wrote:

> Hi Fabiano,
>
> Is this what you are looking for?
> https://stat.ripe.net/widget/rpki-by-trust-anchor
>
> Cheers,
> Nathalie Trenaman
> RIPE NCC
>
> Op 24 aug. 2020, om 15:21 heeft Fabiano D'Agostino <
> fabiano.dagostin...@gmail.com> het volgende geschreven:
>
> Hi all,
> I would like to ask you if there is some information about ROA coverage of
> IPv4/v6 address space in the different RIRs.
>
> Thanks in advance.
>
> Regards,
>
> Fabiano
>
>
>

Re: ROA coverage info

[Di Ma]

FYI

https://www.nro.net/wp-content/uploads/rpki-uploads/rir-adoption.txt

Di  

> 2020年8月24日 21:21，Fabiano D'Agostino  写道：
> 
> Hi all,
> I would like to ask you if there is some information about ROA coverage of 
> IPv4/v6 address space in the different RIRs.
> 
> Thanks in advance.
> 
> Regards,
> 
> Fabiano

Re: ROA coverage info

[Aftab Siddiqui]

+1 to RIPE stats.

Here is from NLnet labs:
https://www.nlnetlabs.nl/projects/rpki/rpki-analytics/

Regards,

Aftab A. Siddiqui


On Tue, 25 Aug 2020 at 00:46, Nathalie Trenaman  wrote:

> Hi Fabiano,
>
> Is this what you are looking for?
> https://stat.ripe.net/widget/rpki-by-trust-anchor
>
> Cheers,
> Nathalie Trenaman
> RIPE NCC
>
> Op 24 aug. 2020, om 15:21 heeft Fabiano D'Agostino <
> fabiano.dagostin...@gmail.com> het volgende geschreven:
>
> Hi all,
> I would like to ask you if there is some information about ROA coverage of
> IPv4/v6 address space in the different RIRs.
>
> Thanks in advance.
>
> Regards,
>
> Fabiano
>
>
>

Re: ROA coverage info

[Nathalie Trenaman]

Hi Fabiano,

Is this what you are looking for?
https://stat.ripe.net/widget/rpki-by-trust-anchor 


Cheers,
Nathalie Trenaman
RIPE NCC

> Op 24 aug. 2020, om 15:21 heeft Fabiano D'Agostino 
>  het volgende geschreven:
> 
> Hi all,
> I would like to ask you if there is some information about ROA coverage of 
> IPv4/v6 address space in the different RIRs.
> 
> Thanks in advance.
> 
> Regards,
> 
> Fabiano

Re: RPKI for dummies

[Randy Bush]

> Some might suggest that a lot of time was spent debating how to do it
> with little actual progress or experimentation done.

this is the internet.  some have suggested pretty much anything.

for the historians in the audience, the first s-bgp, what we would now
call testathon i guess, was held at u oregon, on the side of the eugene
nanog in either 1999 or 2000.  a few large isps, bbn folk, ...  this was
where ops met crypto theorists and started s-bgp's evolution into the
separate threads of rpki, rov, and bgpsec.  

randy

ROA coverage info

[Fabiano D'Agostino]

Hi all,
I would like to ask you if there is some information about ROA coverage of
IPv4/v6 address space in the different RIRs.

Thanks in advance.

Regards,

Fabiano

Re: atmark trading

[Positively Optimistic]

This thread is equally spammish. No one cares.

On Sat, Aug 22, 2020 at 16:54 Bryan Holloway  wrote:

> It's not sales; it's some dumb mailing list managed by "Soundest", which
>
> is now owned by "Omnisend", which sounds even less fun than its
> predecessor.
>
>
>
> Atmark's web-site has no contacts or management information listed other
>
> than "info@", otherwise I would do what you suggest.
>
>
>
> I don't have the patience to call their 800 number and talk to someone
>
> who has zero interest in getting me off of their mailing-list, assuming
>
> the drone has even an inkling of what I'm talking about.
>
>
>
>
>
> On 8/22/20 10:44 PM, Mike Hale wrote:
>
> > I've found it useful to email management if certain sales people refuse
>
> > to stop contacting you.
>
> >
>
> > On Sat, Aug 22, 2020, 1:34 PM Bryan Holloway 
> > > wrote:
>
> >
>
> > Tired of receiving spam from these jamokes.
>
> >
>
> > https://www.atmarktrade.com/
>
> >
>
> > Atmark Trading out of Chicago.
>
> >
>
> > Have tried unsubscribing numerous times; e-mailed their "info"
> accounts
>
> > to no avail.
>
> >
>
> > My only recourse, now, is to shame.
>
> >
>
> > Doubt it will do any good, but if anyone has a contact who can
> actually
>
> > get us off their ridiculous mailing-list -- 3 to 4 e-mails a day --,
>
> > well, I'm all ears.
>
> >
>
> > If not, well, don't do business with these bozos.
>
> >
>
> > /rant
>
> >
>
> > Happy Weekend ...
>
> >
>
>

Re: Ipv6 help

[Roman Tatarnikov]

I've been looking into implementing 646XLAT, however I found the problem ends 
up with clients' routers.

When you give them Ethernet cable that has internet on it, whatever it gets 
plugged into must support CLAT in order for 646XLAT to work. I was not able to 
find any small devices that support it natively, at least according to their 
description. The only way I found to enable CLAT support is to flash those 
devices with OpenWRT, which is not really an option when you are giving away 
those tiny boxes to residential clients when they sign up with you.

So for now we're stuck with CGNAT. :( I do hope I'm wrong and you can tell me 
which device works with 646XLAT out of the box. And hopefully it's something 
TRENDnet's.

-- 
Roman V Tatarnikov
https://linkedin.com/in/rtatarnikov
W: 310 929 2607 | C: 805 746 2886

Re: RPKI for dummies

[Rayhaan Jaufeerally (NANOG)]

[sorry if you're getting this twice, I accidentally sent from the wrong
address and it was rejected from the list]
Hi Dovid,

BGPSEC (as specified in RFC8205 ) is
the next level of routing security which provides the kind of in-band
guarantees that you describe. In my view, RPKI with its ROAs is a stepping
stone to get to an end state where BGPSEC can be deployed and routes
validated end-to-end in the BGP control plane itself. Specifically, RPKI
gets the roots of trust out there, and in use, and these can then be used
in the future to bootstrap the BGPSEC ecosystem (RFC 8209
 proposes a certificate profile for
BGPSEC based on the RPKI)

>From what I have seen, there are some roadblocks to widespread adoption of
BGPSEC, notably:

   - I'm not aware of any ready to use out of the box implementations of
   RFC8205 on off the shelf routers from major vendors,
  - There is a patch to BIRD
(site
  appears down ATM, but referenced from:
  https://bird.network.cz/pipermail/bird-users/2015-August/009877.html)
  and a variant of Quagga
  

which
  supports BGPSEC, though.
   - There will be increased memory and CPU requirements for routers
   performing these validations in the control plane

I think the offloading approach we've seen with RPKI validators running on
another host would be an interesting one to consider as it could relieve
the need for routers themselves to be upgraded with more performant
hardware to perform the required signature verifications etc.

I found this presentation

to
be very informative about BGPSEC's guarantees and failure modes, it's a few
years old but still provides a nice overview.

Hope that helps,
Rayhaan

Disclaimer: any and all views expressed here are those of myself in a
personal capacity, and not necessarily those of my employer.


On Sun, Aug 23, 2020 at 2:43 PM Dovid Bender  wrote:

> Ok. So here is another n00b question. Why don't we have something where
> when we advertise IP space we also pass along a cert that can
> independently be verified by going back to the RIR to see if that cert was
> signed by them. This would also stop someone spoofing my ASN.
>
>
> On Thu, Aug 20, 2020 at 10:53 AM Tom Beecher  wrote:
>
>> ROA = Route Origin Authorization . Origin is the key word.
>>
>> When you create an signed ROA and do all the publishing bits, RPKI
>> validator software will retrieve that , validate the signature, and pass
>> that up to routers, saying "This prefix range that originates from this ASN
>> is valid." Then, any BGP advertisement that contains a prefix in that
>> range, with an origin ASN that matches, is treated as valid. The
>> intermediary as-path isn't a factor.
>>
>> If another ASN ORIGINATES an announcement for your space, then RPKI
>> routers will treat that announcement as INVALID, because that isn't
>> authorized.
>>
>> If another ASN spoofs your ASN , pretending that they are your upstream,
>> RPKI won't solve that. But that is a different problem set.
>>
>> On Thu, Aug 20, 2020 at 10:02 AM Dovid Bender 
>> wrote:
>>
>>> Fabien,
>>>
>>> Thanks. So to sum it up there is nothing stopping a bad actor from
>>> impersonating me as if I am BGP'ing with them. It's to stop any other AS
>>> other then mine from advertising my IP space. Is that correct? How is
>>> verification done? They connect to the RIR and verify that there is  a cert
>>> signed by the RIR for my range?
>>>
>>>
>>>
>>> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
>>> nanog@nanog.org> wrote:
>>>
 Hi,

 In fact, RPKI does nothing about AS Path checks if it's your question.
 RPKI is based on ROA where signatures are published to guarantee you're the
 owner of a specific prefix with optionnal different maxLength from your
 ASN.

 So if the question is about if RPKI is sufficient to secure the whole
 BGP path, well, it's not. RPKI guarantee / permit only to verify the
 ressource announcements (IPvX block) is really owned by your ASN. But even
 if it's not sufficient, we need to deploy it to start securing resources',
 not the whole path.

 Don't know if it replies to your question, but you can read also the
 pretty good documentation on RPKI here :
 https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
 corresponding RFC ;)

 Le 20-08-2020 15:20, Dovid Bender a écrit :

 Hi,

 I am sorry for the n00b question. Can someone help point me in the
 right direction to understand how RPKI works? I understand that from my
 side that I create a key, submit the public portion to ARIN and then send a
 signed 

Re: RPKI for dummies

[Robert Raszuk]

Sure thing :)

Btw my point was to avoid the potential impression that origin validation
brings any real security to bgp.

Cheers,
R.


On Mon, Aug 24, 2020 at 3:12 PM John Kristoff  wrote:

> On Mon, 24 Aug 2020 13:01:15 +
> Robert Raszuk  wrote:
>
> > I would not say that either S-BGP nor so-BGP were precursors to BGP
> > origin validation ( I am assuming this is what you are referring to
> > as "system we have today").
>
> I would consider origin validation as just one application of the
> system we have today.  Does that sound better?
>
> John
>

Re: RPKI for dummies

[John Kristoff]

On Mon, 24 Aug 2020 13:01:15 +
Robert Raszuk  wrote:

> I would not say that either S-BGP nor so-BGP were precursors to BGP
> origin validation ( I am assuming this is what you are referring to
> as "system we have today").

I would consider origin validation as just one application of the
system we have today.  Does that sound better?

John

Re: RPKI for dummies

[Robert Raszuk]

John,

> Two precursors to the system we have today.

I would not say that either S-BGP nor so-BGP were precursors to BGP origin
validation ( I am assuming this is what you are referring to as "system we
have today").

If I recall, securing BGP and validating src ASN were independent projects
both aiming at completely different goals. Former was to assure no one
could hijack your prefixes along the path and latter to detect someone fat
fingering your prefix or ASN.

Thx,
R.



On Mon, Aug 24, 2020 at 2:43 PM John Kristoff  wrote:

> On Sun, 23 Aug 2020 12:40:19 +
> Dovid Bender  wrote:
>
> > Ok. So here is another n00b question. Why don't we have something
> > where when we advertise IP space we also pass along a cert [...]
>
> Take a look at:
>
>   Stephen Kent, Charles Lynn, and Karen Seo. 2000. Secure border gateway
>   protocol (S-BGP). IEEE Journal on Selected areas in Communications 18, 4
> (2000),
>   582–592.
>
> and
>
>   Russ White. 2003. Securing BGP: soBGP. Internet Protocol Journal 6, 3
>   (Sept. 2003), 15–22.
>
> Two precursors to the system we have today.  Both proposed some form of
> including PKI-related matter in BGP messages.  Neither system gained
> much actual traction outside of the design phase as far as I know.
> Some might suggest that a lot of time was spent debating how to do it
> with little actual progress or experimentation done.  The current
> approach has echoes of those ideas with the obvious difference as you
> imply, it is independent from BGP.  This poses some challenges to
> providing a complete solution, but was probably necessary for deployment
> and might prove useful if something other than wants to BGP uses it.
>
> John
>

Re: RPKI for dummies

[John Kristoff]

On Sun, 23 Aug 2020 12:40:19 +
Dovid Bender  wrote:

> Ok. So here is another n00b question. Why don't we have something
> where when we advertise IP space we also pass along a cert [...]

Take a look at:

  Stephen Kent, Charles Lynn, and Karen Seo. 2000. Secure border gateway
  protocol (S-BGP). IEEE Journal on Selected areas in Communications 18, 4 
(2000),
  582–592.

and

  Russ White. 2003. Securing BGP: soBGP. Internet Protocol Journal 6, 3
  (Sept. 2003), 15–22.

Two precursors to the system we have today.  Both proposed some form of
including PKI-related matter in BGP messages.  Neither system gained
much actual traction outside of the design phase as far as I know.
Some might suggest that a lot of time was spent debating how to do it
with little actual progress or experimentation done.  The current
approach has echoes of those ideas with the obvious difference as you
imply, it is independent from BGP.  This poses some challenges to
providing a complete solution, but was probably necessary for deployment
and might prove useful if something other than wants to BGP uses it.

John