Summer of Hijacks: My message to RIPE and the RIPE Executive Board

[Ronald F. Guilmette]

Found yet another big hijacking operation.  Coming out of RIPEland, again.
See below for full details.

I didn't really want to post again to NANOG on this topic (hijacks) quite
this soon, but the bloody European crooks, spammers, and hijackers aren't
really giving me a break, and I can't abide just sitting in silence and
stewing about it for another month or three.  I mean this stuff is just
getting ridiculous.  And I do wory that the Internet community is just
starting to accept this stuff as "normal behavior", which it isn't.

Maybe the following will finally get somebody's attention in RIPEland,
but I'm not holding my breath for what I personally consider a Good
Outcome (which would include full disclosure about what the hell they
are actually going to do about any of this, which is probably far too
much to even hope for).

I'll probably be permanently banned from all of the relevant RIPE mailing
lists for having posted this.  I just skimmed over RIPE's Code of Conduct
for their mailing lists and it basically says that Thou Shalt Not Say
Anything Bad About Anybody Specifically, Ever, and I'm pretty sure that
I just broke that rule, in spades.

Oh well.  May God bless the First Amendment, and may God bless NANOG!

P.S.  It was just now brough to my attention that AS197328, Istanbuldc,
is -only- routing 176.116.0.0/19, which looks to be one of the few
routes that are maintained by MNT-SERVERSGET that are actually for
legitimately allocated IPv4 blocks.

For the record, I do not dispute that some of the routes maintained by
MNT-SERVERSGET are for legitimately allocated space.  I will and do
however dispute any assertion that ALL such routes are for IP space that
has been legitimately allocated to either Mr. Alexander Samuilov or to
his various corporate identities or corporate partners.  That does not
appear to be the case, based on the evidence.

(note - minor edits applied)
==
From: "Ronald F. Guilmette" 
To: exec-bo...@ripe.net, db...@ripe.net, routing...@ripe.net,
anti-abuse...@ripe.net, n...@ripe.net,
Subject: The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top


The entire set of objects in the RIPE WHOIS data base that are currently
registered with mnt-by: MNT-SERVERSGET is listed here:

https://pastebin.com/raw/GiYWxHMh

Among this set of objects there are 235 separate route objects.

Evidence indicates persuasively that some sizable fraction of these RIPE-
registered route objects are fradulent and are simply there to provide
cover for multiple IPv4 address block hijacks.

The presence of these objects in the data base permits the following
set of ASNs to claim that they are acting "legitimately" even as they
route these hijacked blocks:

AS9009 M247 Ltd (UK)
AS43350NFOrce Internet Sevices (Netherlands)
AS57129Optibit, LLC (Russia)
AS197328   Istanbuldc Veri Merkezi Ltd. Sti (Turkey) -- SEE NOTE ABOVE
AS202287   Men Danil Valentinovich (Russia)
AS204895   Santa Plus, LLC (Russia)

The total amount of IPv4 space encompassed within the set of route objects
registered with mnt-by: MNT-SERVERSGET at the present time amounts to
eight hundred and fifty nine (859) /24 blocks.  Of these, only three
hundred and five (305) actually have correctly functioning and properly
delegated reverse DNS at the present time, and even among those, only
two hundred and two (202) have functioning reverse DNS delegations to
the prefered name servers of MNT-SERVERSGET, which is to say the name
servers ns5.dnsget.top and ns6.dnsget.top.

The bottom line is that it appears that, at the present time, something
less than 1/4 of all of the IPv4 address space currently registered in the
RIPE data base (via route objects) by and to MNT-SERVERSGET is space for
which a plausible case could be made that the blocks in question are actually
legitimately assigned to and/or under the legitimate control of MNT-SERVERSGET
aka Mr. Alexander Samuilov.  The other 3/4ths of the IPv4 space in question
has provenance which is, at best, dubious.

Due to its use of little country-of-registration flags for each IP address
block, the web site bgp.he.net provides the most visually obvious indications
of at least two of the specific block hijacks in this case, specifically
the hijacks of 27.103.192.0/19 and 36.0.192.0/19 by AS57129:

https://bgp.he.net/AS57129#_prefixes

Based upon the foregoing, I hereby respectfully request RIPE NCC to undertake
an immediate and conmprehensive review of all objects in the data base that
are currently registered with mnt-by: MNT-SERVERSGET.

Additionally, I also respectfully request RIPE NCC to publish the results
of this review to the mailing lists of the Database Working Group and the
Anti-Abuse Working Group.  The charters of both of these Working Groups 
are directly relevant to this issue, and there exists neither need nor
reason to simply sweep this issue quietly under the carpet, 

Re: Feedback - SBC Vendors.

[Shawn Ritchie]

I second what's been said about ACME Packet; loved them when we first got
them, phasing them out now in favor of Ribbon due to what a pain Oracle has
been to deal with.

We're all hardware on the Ribbon side, using both the 5k line and some
premise 1k SBC's. They've been fine so far.

On Thu, Aug 9, 2018 at 9:26 AM Ryan Finnesey  wrote:

> Thanks I will post there as well
>
>
>
>
>
>
>
> 
> From: Hiers, David 
> Sent: Thursday, August 9, 2018 10:11:33 AM
> To: James Milko; Ryan Finnesey
> Cc: nanog@nanog.org
> Subject: RE: Feedback - SBC Vendors.
>
> You might want to drop this question on the VoiceOps list:
>
> voice...@voiceops.org
>
> It runs at a good signal-to-noise ratio, so you'll get some useful
> responses.
>
>
> David
>
>
> -Original Message-
> From: NANOG [mailto:nanog-bounces+david.hiers=cdk@nanog.org] On
> Behalf Of James Milko
> Sent: Thursday, August 09, 2018 7:06 AM
> To: Ryan Finnesey 
> Cc: nanog@nanog.org
> Subject: Re: Feedback - SBC Vendors.
>
>  Which Ribbon product are you looking at?  There are quite a few now and
> they have different code bases/features.
>
> JM
>
> On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey  wrote:
>
> > I am going to have to install a series of SBCs for a  voice offering
> > connected to Microsoft Teams.  We are going to pass the SIP traffic
> > off to a larger number of SIP providers.  I would like  to get some
> > feedback from the group on SBC vendors.  I have two options for
> > vendors Ribbon or AudioCodes.  I am leaning towards a software based SBC
> over an appliance.
> >
> > Would be helpful to get the other members feedback on Ribbon or
> > AudioCodes deployments within their networks.
> >
> > Cheers
> > Ryan
> >
> >
>
> --
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>


-- 
Shawn

Re: Multicast traffic % in enterprise network ?

[Greg Shepherd]

On Thu, Aug 9, 2018 at 11:41 AM, Curtis, Bruce 
wrote:

>
> Multicast was also required for earlier versions of VXLAN.  But later
> versions or VXLAN only require unicast.
>
> For the far future it seems like Named Data Neworking, Content Centric
> Networking, Information Centric Networking, Data Centric Networking etc all
> list multicast as a requirement or fundamental part of their architecture.


And they would all be better served by using BIER.

Greg


> > On Aug 8, 2018, at 4:15 PM, Greg Shepherd  wrote:
> >
> > Financial exchanges around the world use multicast.
> >
> > On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber  wrote:
> >
> >> As someone else remarked, part of this will depend on the type of
> network
> >> you are profiling. One enterprise networking may have critical internal
> >> applications that depend on multicast to work and others may have
> nothing
> >> but the basic requirements of the network itself (e.g. IPv6 uses
> multicast
> >> instead of broadcast for some network control information distribution).
> >>
> >> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG <
> >> nanog@nanog.org> wrote:
> >>
> >>> Hi Every one,
> >>> Recently we had good discussion over multicast uses in public internet.
> >>> From discussion, it was pointed out uses of multicast is more with in
> >>> enterprise.  Wanted to understand how much % multicast traffic present
> in
> >>> network
> >>>
> >>>  *   If there is any data which can provide what % of traffic is
> >>> multicast traffic. And if multicast is removed, how much unicast
> traffic
> >> it
> >>> would add up?
> >>>  *   Since this forum has people from deployment area, I would love to
> >>> know if there is real deployment problems or its pain to deploy
> >> multicast.
> >>>
> >>>
> >>> These questions is to work / discussion in IETF to see what is pain
> >> points
> >>> for multicast, and how can we simplify it.
> >>>
> >>>
> >>>
> >>> Thanks
> >>> Mankamana
> >>>
> >>>
> >>
>
>
> ---
> Bruce Curtis bruce.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
>
>

Yahoo Groups contact

[Andy Ringsmuth]

Any chance someone here has admin/troubleshooting involvement with Yahoo 
Groups, or knows someone who does?

Much appreciated.




Andy Ringsmuth
a...@newslink.com
5609 Harding Dr.
Lincoln, NE 68521
(402) 304-0083 cellular

Re: Multicast traffic % in enterprise network ?

[Curtis, Bruce]

Multicast was also required for earlier versions of VXLAN.  But later versions 
or VXLAN only require unicast.

For the far future it seems like Named Data Neworking, Content Centric 
Networking, Information Centric Networking, Data Centric Networking etc all 
list multicast as a requirement or fundamental part of their architecture.

> On Aug 8, 2018, at 4:15 PM, Greg Shepherd  wrote:
> 
> Financial exchanges around the world use multicast.
> 
> On Wed, Aug 8, 2018 at 1:31 PM, Stan Barber  wrote:
> 
>> As someone else remarked, part of this will depend on the type of network
>> you are profiling. One enterprise networking may have critical internal
>> applications that depend on multicast to work and others may have nothing
>> but the basic requirements of the network itself (e.g. IPv6 uses multicast
>> instead of broadcast for some network control information distribution).
>> 
>> On Wed, Aug 8, 2018 at 11:49 AM, Mankamana Mishra (mankamis) via NANOG <
>> nanog@nanog.org> wrote:
>> 
>>> Hi Every one,
>>> Recently we had good discussion over multicast uses in public internet.
>>> From discussion, it was pointed out uses of multicast is more with in
>>> enterprise.  Wanted to understand how much % multicast traffic present in
>>> network
>>> 
>>>  *   If there is any data which can provide what % of traffic is
>>> multicast traffic. And if multicast is removed, how much unicast traffic
>> it
>>> would add up?
>>>  *   Since this forum has people from deployment area, I would love to
>>> know if there is real deployment problems or its pain to deploy
>> multicast.
>>> 
>>> 
>>> These questions is to work / discussion in IETF to see what is pain
>> points
>>> for multicast, and how can we simplify it.
>>> 
>>> 
>>> 
>>> Thanks
>>> Mankamana
>>> 
>>> 
>> 


---
Bruce Curtis bruce.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University

Re: PPPoE Server

[Mauro Gasparini]

In fact, today I also received comments about the preferences with 
Juniper, even with its BNG software mounted on a server.

Thank you all for the responses.



El 08/08/18 a las 18:11, Tony Wicks escribió:

Cisco ASR1k can support up to 64K PPPoE depending on the model/cards. Juniper 
MX and Nokia 7750 can scale up to a couple of hundred thousands depending on 
the model. The thing to bear in mind is the ASR1000 is a CPU based router, this 
means it is very flexible (NAT/L2TP etc can just turn on without extra cards) 
but throughput is limited to your processor capacity and what you turn on. The 
Juniper MX and Nokia 7750 are more hardware based routers that can massively 
scale but you need to work closely with the vendor to ensure you have 
appropriate cards for your intended application. Personally I have used all of 
these solutions and I would stray towards the Juniper. This being said the 
Nokia is also a magnificent box albeit a bit less user friendly IMHO.



-Original Message-
From: NANOG  On Behalf Of Clayton Zekelman
Sent: Thursday, 9 August 2018 8:50 AM
To: Jose Jorquera ; Mauro Gasparini 

Cc: nanog@nanog.org
Subject: Re: PPPoE Server


I'll second that. Juniper MX works well for us.  We have one router terminating 
10,000 PPPoE and 3,500 L2TP and it handles the load fine.


At 04:43 PM 08/08/2018, Jose Jorquera wrote:

Cisco is the any option? I read about BRAS server on Juniper MX-480,can
you check "Juniper one day: dynamic subscriber management” for more
info.


El 08-08-2018, a las 15:22, Mauro Gasparini

 escribió:

Good afternoon people.
I would like to advice me some appliance or

software (running on top level server line) which supports 20,000
simultaneous PPPoE connections.

The customer has a Cisco ASR1000 but I don't

have any confirmed experience that can support it.

Mauro Gasparini.

Re: PPPoE Server

[Steven Karp]

For 20,000 sessions two or more Juniper VMX routers can share the BNG / BRAS 
licensing and provide high availability.

The BNG licenses for hardware based MX routers are tied to the chassis and 
cannot be shared between multiple routers.

Sent from my mobile device

> On Aug 8, 2018, at 4:13 PM, Tony Wicks  wrote:
> 
> Cisco ASR1k can support up to 64K PPPoE depending on the model/cards. Juniper 
> MX and Nokia 7750 can scale up to a couple of hundred thousands depending on 
> the model. The thing to bear in mind is the ASR1000 is a CPU based router, 
> this means it is very flexible (NAT/L2TP etc can just turn on without extra 
> cards) but throughput is limited to your processor capacity and what you turn 
> on. The Juniper MX and Nokia 7750 are more hardware based routers that can 
> massively scale but you need to work closely with the vendor to ensure you 
> have appropriate cards for your intended application. Personally I have used 
> all of these solutions and I would stray towards the Juniper. This being said 
> the Nokia is also a magnificent box albeit a bit less user friendly IMHO.
> 
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of Clayton Zekelman
> Sent: Thursday, 9 August 2018 8:50 AM
> To: Jose Jorquera ; Mauro Gasparini 
> 
> Cc: nanog@nanog.org
> Subject: Re: PPPoE Server
> 
> 
> I'll second that. Juniper MX works well for us.  We have one router 
> terminating 10,000 PPPoE and 3,500 L2TP and it handles the load fine.
> 
> 
> At 04:43 PM 08/08/2018, Jose Jorquera wrote:
>> Cisco is the any option? I read about BRAS server on Juniper MX-480,can 
>> you check "Juniper one day: dynamic subscriber management” for more 
>> info.
>> 
>>> El 08-08-2018, a las 15:22, Mauro Gasparini
>>  escribió:
>>> 
>>> Good afternoon people.
>>> I would like to advice me some appliance or
>> software (running on top level server line) which supports 20,000 
>> simultaneous PPPoE connections.
>>> The customer has a Cisco ASR1000 but I don't
>> have any confirmed experience that can support it.
>>> 
>>> Mauro Gasparini.
>>> 
>>> 
> 

Re: Multicast traffic % in enterprise network ?

[James Bensley]

On 9 August 2018 at 13:57, Saku Ytti  wrote:
> On Thu, 9 Aug 2018 at 15:27, James Bensley  wrote:
>
>> A recent customer uses multicast to have the same packet arrive at
>> multiple destinations at the same time for resilience (their own
>> internal systems, not IPTV or media etc). Having just refreshed their
>> network for the next 5-10 years it's not going away anytime soon.
>
> I believe the same time delivery is motivation for stock exchanges
> too. One of the larger exchanges used MX and multicast, which of
> course does btree or utree (in this  case utree) replication, which
> makes delivery times are very much variant.
> So it is very much implementation detail what type of delivery time
> differences to expect in different ports and it is not by design
> superior to unicast.


I'm definately not saying it was a good idea / good design :)

I'm just saying that it's another example of multicast in use that is
not the usual IPTV or financial trading (aeronautical in this case).

Cheers,
James.

RE: Feedback - SBC Vendors.

[Ryan Finnesey]

Thanks I will post there as well








From: Hiers, David 
Sent: Thursday, August 9, 2018 10:11:33 AM
To: James Milko; Ryan Finnesey
Cc: nanog@nanog.org
Subject: RE: Feedback - SBC Vendors.

You might want to drop this question on the VoiceOps list:

voice...@voiceops.org

It runs at a good signal-to-noise ratio, so you'll get some useful responses.


David


-Original Message-
From: NANOG [mailto:nanog-bounces+david.hiers=cdk@nanog.org] On Behalf Of 
James Milko
Sent: Thursday, August 09, 2018 7:06 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: Feedback - SBC Vendors.

 Which Ribbon product are you looking at?  There are quite a few now and they 
have different code bases/features.

JM

On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey  wrote:

> I am going to have to install a series of SBCs for a  voice offering
> connected to Microsoft Teams.  We are going to pass the SIP traffic
> off to a larger number of SIP providers.  I would like  to get some
> feedback from the group on SBC vendors.  I have two options for
> vendors Ribbon or AudioCodes.  I am leaning towards a software based SBC over 
> an appliance.
>
> Would be helpful to get the other members feedback on Ribbon or
> AudioCodes deployments within their networks.
>
> Cheers
> Ryan
>
>

--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

RE: Feedback - SBC Vendors.

[Hiers, David]

You might want to drop this question on the VoiceOps list:

voice...@voiceops.org

It runs at a good signal-to-noise ratio, so you'll get some useful responses.


David


-Original Message-
From: NANOG [mailto:nanog-bounces+david.hiers=cdk@nanog.org] On Behalf Of 
James Milko
Sent: Thursday, August 09, 2018 7:06 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: Feedback - SBC Vendors.

 Which Ribbon product are you looking at?  There are quite a few now and they 
have different code bases/features.

JM

On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey  wrote:

> I am going to have to install a series of SBCs for a  voice offering 
> connected to Microsoft Teams.  We are going to pass the SIP traffic 
> off to a larger number of SIP providers.  I would like  to get some 
> feedback from the group on SBC vendors.  I have two options for 
> vendors Ribbon or AudioCodes.  I am leaning towards a software based SBC over 
> an appliance.
>
> Would be helpful to get the other members feedback on Ribbon or 
> AudioCodes deployments within their networks.
>
> Cheers
> Ryan
>
>

--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

RE: Feedback - SBC Vendors.

[Ryan Finnesey]

I was looking at SBC SWe (Software Edition)  I think the same code base as the 
- SBC 5400 – appliance.



From: James Milko 
Sent: Thursday, August 9, 2018 10:06 AM
To: Ryan Finnesey 
Cc: nanog@nanog.org
Subject: Re: Feedback - SBC Vendors.

Which Ribbon product are you looking at?  There are quite a few now and they 
have different code bases/features.

JM

On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey 
mailto:r...@finnesey.com>> wrote:
I am going to have to install a series of SBCs for a  voice offering connected 
to Microsoft Teams.  We are going to pass the SIP traffic off to a larger 
number of SIP providers.  I would like  to get some feedback from the group on 
SBC vendors.  I have two options for vendors Ribbon or AudioCodes.  I am 
leaning towards a software based SBC over an appliance.

Would be helpful to get the other members feedback on Ribbon or AudioCodes 
deployments within their networks.

Cheers
Ryan

Re: Feedback - SBC Vendors.

[James Milko]

 Which Ribbon product are you looking at?  There are quite a few now and
they have different code bases/features.

JM

On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey  wrote:

> I am going to have to install a series of SBCs for a  voice offering
> connected to Microsoft Teams.  We are going to pass the SIP traffic off to
> a larger number of SIP providers.  I would like  to get some feedback from
> the group on SBC vendors.  I have two options for vendors Ribbon or
> AudioCodes.  I am leaning towards a software based SBC over an appliance.
>
> Would be helpful to get the other members feedback on Ribbon or AudioCodes
> deployments within their networks.
>
> Cheers
> Ryan
>
>

Re: Akamai Contact

[Jared Mauch]

Replied offlist

Jared Mauch

> On Aug 8, 2018, at 3:33 PM, Jawaid Bazyar  
> wrote:
> 
> Hi, having trouble engaging with an Akamai contact in relation to the server 
> stack we have here. Feel free to contact me.
> 
> -- 
> 
> Jawaid Bazyar
> 
> President
> 
> ph 303.815.1814
> 
> fax 303.815.1001
> 
> jawaid.baz...@forethought.net 
>

Re: Multicast traffic % in enterprise network ?

[Saku Ytti]

On Thu, 9 Aug 2018 at 15:27, James Bensley  wrote:

> A recent customer uses multicast to have the same packet arrive at
> multiple destinations at the same time for resilience (their own
> internal systems, not IPTV or media etc). Having just refreshed their
> network for the next 5-10 years it's not going away anytime soon.

I believe the same time delivery is motivation for stock exchanges
too. One of the larger exchanges used MX and multicast, which of
course does btree or utree (in this  case utree) replication, which
makes delivery times are very much variant.
So it is very much implementation detail what type of delivery time
differences to expect in different ports and it is not by design
superior to unicast.

-- 
  ++ytti

Re: Multicast traffic % in enterprise network ?

[James Bensley]

On 8 August 2018 at 19:49, Mankamana Mishra (mankamis) via NANOG
 wrote:
> Hi Every one,
> Recently we had good discussion over multicast uses in public internet. From 
> discussion, it was pointed out uses of multicast is more with in enterprise.  
> Wanted to understand how much % multicast traffic present in network
>
>   *   If there is any data which can provide what % of traffic is multicast 
> traffic. And if multicast is removed, how much unicast traffic it would add 
> up?
>   *   Since this forum has people from deployment area, I would love to know 
> if there is real deployment problems or its pain to deploy multicast.
>
>
> These questions is to work / discussion in IETF to see what is pain points 
> for multicast, and how can we simplify it.

A recent customer uses multicast to have the same packet arrive at
multiple destinations at the same time for resilience (their own
internal systems, not IPTV or media etc). Having just refreshed their
network for the next 5-10 years it's not going away anytime soon.

Cheers,
James.

Re: Multicast traffic % in enterprise network ?

[Thomas Bellman]

On 2018-08-08 23:36, na...@jack.fr.eu.org wrote:

> Let me fix that for you.
> Using multicast on IPv6 grant us the ability to do more.
> Today, this is worthless.
> Will it be the same tomorrow ?

Problem is, to handle the Neigbour Discovery design (16M multicast
groups), we need hardware that does not exist yet, is unlikely to
exist for at least another decade and will not be down to reasonable
prices (< 5 kUSD) for even longer.  In the meantime, IPv6 neigbour
discovery *precludes* the use of multicast for other purposes on
non-small networks, because IPv6 ND will use up all multicast groups.

If ND had limited itself to 256 multicast groups, it wouldn't have
been a problem.

> Multicast without NDP is broadcast,

(With s/NDP/MLD/ as you yourself mentioned.)

That's the case for Ethernet.  Hop over to the Infiniband or OmniPath
world, and multicast without MLD will cause packets to be dropped.
There is no such thing as broadcast on IB or OPA.

(At least OmniPath does have something called "multicast LID sharing",
where the IPv6 ND groups are clamped down to just 512 distinct groups,
but I haven't read up on the details for how that works, yet.  I don't
know offhand if there is something similar for Infiniband.)


/Bellman



signature.asc
Description: OpenPGP digital signature