Re: Verizon wireless to stop issuing static IPv4

[Constantine A. Murenin]

On 08/03/2017, Miles Fidelman  wrote:
> Seems to me that the only people who get static, wireless, IP addresses
> are people who put sensors on vehicles and IoT applications.  Who gets a
> static IP for a phone?  This might cause some serious heartburn for my
> previous employer - who built CAD systems for transit buses.
>
> Miles Fidelman

With how much memory and processing power any modern
internet-connected device has, plus the ever ubiquitous cloud, I don't
understand why IoT, especially non-consumer-grade IoT, should have any
need for public IPv4 addresses.

Even if you have a very legacy app, and IPsec is too complex for your
needs, doing an SSH session with OpenSSH and its port forwarding
feature is just too simple to pass up.  http://mdoc.su/o/ssh.1

I mean, come on, if malware vendors have no need for public IP
addresses to take control of your IoT and perform C&C, you're clearly
doing something wrong if your own shit doesn't work without it.

Cheers,
http://Constantine.SU/

Re: Verizon wireless to stop issuing static IPv4

[Christopher Morrow]

On Wed, Mar 8, 2017 at 10:58 PM,  wrote:

> On Wed, 08 Mar 2017 22:08:59 -0500, Christopher Morrow said:
> > > previous employer - who built CAD systems for transit buses.
> > on the bright side they can just get fios or dsl (depending on location)
> ..
> > you know you can still get v4 there, and won't even have to worry about
> > that pesky new fangled ipv6 .
>
> FIOS for a transit bus?
>
>
it seems as likely to be true as ipv6 on fios, yes.

Re: Verizon wireless to stop issuing static IPv4

[valdis . kletnieks]

On Wed, 08 Mar 2017 22:08:59 -0500, Christopher Morrow said:
> > previous employer - who built CAD systems for transit buses.
> on the bright side they can just get fios or dsl (depending on location) ..
> you know you can still get v4 there, and won't even have to worry about
> that pesky new fangled ipv6 .

FIOS for a transit bus?



pgpTC_2aqCOu6.pgp
Description: PGP signature

Re: Verizon wireless to stop issuing static IPv4

[Ca By]

On Wed, Mar 8, 2017 at 7:10 PM Christopher Morrow 
wrote:

> On Wed, Mar 8, 2017 at 9:27 PM, Miles Fidelman  >
> wrote:
>
> > Seems to me that the only people who get static, wireless, IP addresses
> > are people who put sensors on vehicles and IoT applications.  Who gets a
> > static IP for a phone?  This might cause some serious heartburn for my
> > previous employer - who built CAD systems for transit buses.
> >
> >
> on the bright side they can just get fios or dsl (depending on location) ..
> you know you can still get v4 there, and won't even have to worry about
> that pesky new fangled



The economics of this is very interesting.

Normally, with scarcity, i would expect price to go up.  VZW is running low
on ipv4  addresses, so they raise prices to stem demand. They acquire ipv4
on the secondary market and pass cost along with mark up to customers 

But -- vzw knows if they raise prices customers will just go elsewhere.
Also, their growth model simply may show that there is no way to meet
demand with ipv4, ipv4 is fundamentally holding back iot growth, so they
need to pivot / move to ipv6 to unchain the growth.

Seems smart. The runway for ipv4 is too short for iot growth. Forcing the
hand to scalable ipv6 now will pay dividends and prevent investment in
unscalable ipv4 solutions

Re: Verizon wireless to stop issuing static IPv4

[Christopher Morrow]

On Wed, Mar 8, 2017 at 9:27 PM, Miles Fidelman 
wrote:

> Seems to me that the only people who get static, wireless, IP addresses
> are people who put sensors on vehicles and IoT applications.  Who gets a
> static IP for a phone?  This might cause some serious heartburn for my
> previous employer - who built CAD systems for transit buses.
>
>
on the bright side they can just get fios or dsl (depending on location) ..
you know you can still get v4 there, and won't even have to worry about
that pesky new fangled ipv6 .

Re: Verizon wireless to stop issuing static IPv4

[Miles Fidelman]

Seems to me that the only people who get static, wireless, IP addresses 
are people who put sensors on vehicles and IoT applications.  Who gets a 
static IP for a phone?  This might cause some serious heartburn for my 
previous employer - who built CAD systems for transit buses.


Miles Fidelman


On 3/8/17 6:13 PM, Luke Guillory wrote:

My customer got the email and the only service they have is wireless. Also 
notice the email address.

From: Verizon Wireless 
mailto:verizonwirele...@email.vzwshop.com>>




Sent from my iPad

On Mar 8, 2017, at 6:44 PM, Keith Stokes 
mailto:kei...@neilltech.com>> wrote:

You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is 
it really all of Verizon, VZ Wireless, home, business or some combination?

On Mar 8, 2017, at 11:16 AM, David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>>
 wrote:

Thought the list would find this interesting.  Just received an email from VZ 
wireless that they’re going to stop selling static IPv4 for wireless 
subscribers in June.  That should make for some interesting support calls on 
the broadband/fios side; one half of the company is forcing ipv6, the other 
can’t provide it.  At least now we have a big name forcing the issue though.

David

Here’s complete text:

On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
due to a shortage of available addresses. Customers that currently have active 
Public Static IPv4 addresses will retain those addresses, and Verizon will 
continue to fully support existing Public Static IPv4 addresses. In order to 
reserve new IP addresses, your company will need to convert to the Persistent 
Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.





Why should you make the move to Persistent Prefix IPv6?





•

Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 
128-bit addressing scheme, which aligns to current international agreements and 
standards.



•

Persistent Prefix IPv6 will provide the device with an IP address unique to 
that device that will remain with that device until the address is relinquished 
by the user (i.e., when the user moves the device off the Verizon Wireless 
network).



•

IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.









---

Keith Stokes







Luke Guillory
Network Operations Manager


 [cid:imagefe9475.JPG@ae2f04c2.45884860] 

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com
Web:www.rtconline.com

 Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.



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

Re: Verizon wireless to stop issuing static IPv4

[Luke Guillory]

My customer got the email and the only service they have is wireless. Also 
notice the email address.

From: Verizon Wireless 
mailto:verizonwirele...@email.vzwshop.com>>




Sent from my iPad

On Mar 8, 2017, at 6:44 PM, Keith Stokes 
mailto:kei...@neilltech.com>> wrote:

You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is 
it really all of Verizon, VZ Wireless, home, business or some combination?

On Mar 8, 2017, at 11:16 AM, David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>>
 wrote:

Thought the list would find this interesting.  Just received an email from VZ 
wireless that they’re going to stop selling static IPv4 for wireless 
subscribers in June.  That should make for some interesting support calls on 
the broadband/fios side; one half of the company is forcing ipv6, the other 
can’t provide it.  At least now we have a big name forcing the issue though.

David

Here’s complete text:

On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
due to a shortage of available addresses. Customers that currently have active 
Public Static IPv4 addresses will retain those addresses, and Verizon will 
continue to fully support existing Public Static IPv4 addresses. In order to 
reserve new IP addresses, your company will need to convert to the Persistent 
Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.





Why should you make the move to Persistent Prefix IPv6?





•

Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 
128-bit addressing scheme, which aligns to current international agreements and 
standards.



•

Persistent Prefix IPv6 will provide the device with an IP address unique to 
that device that will remain with that device until the address is relinquished 
by the user (i.e., when the user moves the device off the Verizon Wireless 
network).



•

IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.









---

Keith Stokes







Luke Guillory
Network Operations Manager


[cid:imagefe9475.JPG@ae2f04c2.45884860] 

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com
Web:www.rtconline.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.

Re: Verizon wireless to stop issuing static IPv4

[Keith Stokes]

You said the e-mail was from VZ wireless but the e-mail text says Verizon. Is 
it really all of Verizon, VZ Wireless, home, business or some combination?

On Mar 8, 2017, at 11:16 AM, David Hubbard 
mailto:dhubb...@dino.hostasaurus.com>> wrote:

Thought the list would find this interesting.  Just received an email from VZ 
wireless that they’re going to stop selling static IPv4 for wireless 
subscribers in June.  That should make for some interesting support calls on 
the broadband/fios side; one half of the company is forcing ipv6, the other 
can’t provide it.  At least now we have a big name forcing the issue though.

David

Here’s complete text:

On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
due to a shortage of available addresses. Customers that currently have active 
Public Static IPv4 addresses will retain those addresses, and Verizon will 
continue to fully support existing Public Static IPv4 addresses. In order to 
reserve new IP addresses, your company will need to convert to the Persistent 
Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.





Why should you make the move to Persistent Prefix IPv6?





•

Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 
128-bit addressing scheme, which aligns to current international agreements and 
standards.



•

Persistent Prefix IPv6 will provide the device with an IP address unique to 
that device that will remain with that device until the address is relinquished 
by the user (i.e., when the user moves the device off the Verizon Wireless 
network).



•

IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.









---

Keith Stokes

Re: CIA Exploits on Mikrotik Hardware /Software

[Tom Smyth]

I got a question from a colleague that highlights an omission / lack of
clarification on my initial mail and i wanted to share...

As far as im aware and from tests i carried out about 7 or 8 years ago The
allowed from ip addresses  in ip services menu uses tcp wrapers and
 actually allows tcp connections from any address (regardless of what ips
you specified) the decision to allow or deny a user login is taken after
the connection is made so there could be a window for the exploit to be
uploaded.
That is why i recommended using the ip firewall instead to enforce the
policy as the ip firewall will act on connection attempts and prevent an
unauthorised src address from making a connection to the box in the first
place

I hope this helps
Tom Smyth

On 8 Mar 2017 3:31 PM, "Tom Smyth"  wrote:

> Hello,
> there were 2 typos on that maiil
>
> 1) I used lads (sorry force of habit)  was meant in the sense of
> Gender Neutrality  as opposed to excluding ladies,
>
> 2) the sample firewall rules had a space missing with the wrong
> address list name :/
>
> I have corrected them below
>
> On Wed, Mar 8, 2017 at 3:17 PM, Tom Smyth 
> wrote:
> > -- Forwarded message --
> > From: Tom Smyth 
> > Date: Wed, Mar 8, 2017 at 3:02 PM
> > Subject: CIA Exploits on Mikrotik Hardware /Software
> > To: INEX Members Technical Mailing List 
> >
> >
> Hello
> >
> > For MikroTik Users in the community there are apparently live exploits
> > for MikroTik software  and apparently this was used by the CIA, if the
> > tools are released in the wild  this would represent a significant
> > threat to your ISPs for those of you who have MikroTik Routers with
> > public IPs on them and if they are not adequately filtered,
> >
> > I would humbly suggest that you apply best practices and filter the
> > management services  and disable any management services that you dont
> > absolutely need,
> >
> > for further details please find the following
> >
> > More Details on the MikroTik CIA Exploits
> > https://forum.mikrotik.com/viewtopic.php?t=119255
> >
> > you can disable un needed administration services in
> > IP/services menu,
> >
> > and I would suggest filtering access to the management ports and
> > disabling the web management interface altogether and disable ftp
> >
> > If you want to protect the Routers apply filters on the input chain of
> > the Firewall Filter,
> >
> > tcp dstport 22 for ssh
> > tcp dstport 8291 for winbox
> > tcp dstport 23 for telnet
> > tcp dstport 8729 api
> > tcp dstport 8728 api
> > tcp dstport 20,21 ftp
> > be aware that the api interfaces could have been enabled if you were
> > upgrading the software from an older version
> >
> >
> > I have included a sample configuration script below just to help But
> > make sure to adjust it to suit your own needs...
> >
> > /ip service
> > set telnet disabled=yes
> > set ftp disabled=yes
> > set www disabled=yes
> > set www-ssl certificate=cert1 disabled=yes
> > set api disabled=yes
> > set api-ssl disabled=yes
> >
> > /ip firewall address-list
> > add address=5.134.88.0/29 list=Management
> >
> > #STOP REPLACE the address above with your management ip ranges
> > #copy the lines to add more ips
> >
> >
> >
> > /ip firewall filter
> > add action=accept chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=22
> > src-address-list=Management protocol=tcp
> > add action=accept chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=8291
> > src-address-list=Management protocol=tcp
> >
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=22 protocol=tcp
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=8291 protocol=tcp
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=23 protocol=tcp
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=21 protocol=tcp
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=8729 protocol=tcp
> > add action=drop chain=input comment="Drop input Rule to protect
> > MikroTik Devices" dst-port=8728 protocol=tcp
> >
> >
> > after running that script on your mikrotik Firewall ensure the rules
> > that you added are moved straight to the top of the firewall  rule set
> > 
> >
> >
> >
> > it is important to note that full details on the exploits are not
> > available but any service that Mikrotik is running could be an entry
> > point so bear that in mind ,
> >
> > eg , NTP  DNS ...  Hotspot , CDP / MNDP / and the long list of VPN
> > services that can be configured on MikroTik...
> >
> >
> > --
> > Kindest regards,
> > Tom Smyth
> >
> > Mobile: +353 87 6193172
> > -
> > PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
> > This email contains information which may be confidential or
> > privileged. The information is 

Re: Verizon wireless to stop issuing static IPv4

[Ed Lopez]

I'm assuming no consideration for using RFC-6598 addresses (100.64.0.0/10)
and performing CGN as a bridge, perhaps via LW4o6


On Wed, Mar 8, 2017 at 12:31 PM Randy Carpenter 
wrote:

>
> It would have been nice if Verizon had starting issuing IPv6 while still
> issuing IPv4 for an easy transition. The current situation is that you
> can't get static IPv6 at all. I have been bugging them about this for many
> years.
>
> thanks,
> -Randy
>
>
> - On Mar 8, 2017, at 12:16 PM, David Hubbard
> dhubb...@dino.hostasaurus.com wrote:
>
> > Thought the list would find this interesting.  Just received an email
> from VZ
> > wireless that they’re going to stop selling static IPv4 for wireless
> > subscribers in June.  That should make for some interesting support
> calls on
> > the broadband/fios side; one half of the company is forcing ipv6, the
> other
> > can’t provide it.  At least now we have a big name forcing the issue
> though.
> >
> > David
> >
> > Here’s complete text:
> >
> > On June 30, 2017, Verizon will stop issuing new Public Static IPv4
> addresses due
> > to a shortage of available addresses. Customers that currently have
> active
> > Public Static IPv4 addresses will retain those addresses, and Verizon
> will
> > continue to fully support existing Public Static IPv4 addresses. In
> order to
> > reserve new IP addresses, your company will need to convert to the
> Persistent
> > Prefix IPv6 requirements and implement new Verizon-certified IPv6
> devices.
> >
> >
> >
> >
> >
> > Why should you make the move to Persistent Prefix IPv6?
> >
> >
> >
> >
> >
> > •
> >
> > Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6
> has
> > 128-bit addressing scheme, which aligns to current international
> agreements and
> > standards.
> >
> >
> >
> > •
> >
> > Persistent Prefix IPv6 will provide the device with an IP address unique
> to that
> > device that will remain with that device until the address is
> relinquished by
> > the user (i.e., when the user moves the device off the Verizon Wireless
> > network).
> >
> >
> >
> > •
> >
> > IPv4-only devices are not compatible with Persistent Prefix IPv6
> addresses.
>
-- 
Ed Lopez | Security Architect | Corsa Technology
Email: ed.lo...@corsa.com
Mobile: +1.703.220.0988
www.corsa.com

sent from my iPad ... I apologize for any auto-correct errors

Re: Verizon wireless to stop issuing static IPv4

[Randy Carpenter]

It would have been nice if Verizon had starting issuing IPv6 while still 
issuing IPv4 for an easy transition. The current situation is that you can't 
get static IPv6 at all. I have been bugging them about this for many years.

thanks,
-Randy


- On Mar 8, 2017, at 12:16 PM, David Hubbard dhubb...@dino.hostasaurus.com 
wrote:

> Thought the list would find this interesting.  Just received an email from VZ
> wireless that they’re going to stop selling static IPv4 for wireless
> subscribers in June.  That should make for some interesting support calls on
> the broadband/fios side; one half of the company is forcing ipv6, the other
> can’t provide it.  At least now we have a big name forcing the issue though.
> 
> David
> 
> Here’s complete text:
> 
> On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
> due
> to a shortage of available addresses. Customers that currently have active
> Public Static IPv4 addresses will retain those addresses, and Verizon will
> continue to fully support existing Public Static IPv4 addresses. In order to
> reserve new IP addresses, your company will need to convert to the Persistent
> Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.
> 
> 
> 
> 
> 
> Why should you make the move to Persistent Prefix IPv6?
> 
> 
> 
> 
> 
> •
> 
> Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has
> 128-bit addressing scheme, which aligns to current international agreements 
> and
> standards.
> 
> 
> 
> •
> 
> Persistent Prefix IPv6 will provide the device with an IP address unique to 
> that
> device that will remain with that device until the address is relinquished by
> the user (i.e., when the user moves the device off the Verizon Wireless
> network).
> 
> 
> 
> •
> 
> IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.

Verizon wireless to stop issuing static IPv4

[David Hubbard]

Thought the list would find this interesting.  Just received an email from VZ 
wireless that they’re going to stop selling static IPv4 for wireless 
subscribers in June.  That should make for some interesting support calls on 
the broadband/fios side; one half of the company is forcing ipv6, the other 
can’t provide it.  At least now we have a big name forcing the issue though.

David

Here’s complete text:

On June 30, 2017, Verizon will stop issuing new Public Static IPv4 addresses 
due to a shortage of available addresses. Customers that currently have active 
Public Static IPv4 addresses will retain those addresses, and Verizon will 
continue to fully support existing Public Static IPv4 addresses. In order to 
reserve new IP addresses, your company will need to convert to the Persistent 
Prefix IPv6 requirements and implement new Verizon-certified IPv6 devices.





Why should you make the move to Persistent Prefix IPv6?





•

Unlike IPv4, which is limited to a 32-bit prefix, Persistent Prefix IPv6 has 
128-bit addressing scheme, which aligns to current international agreements and 
standards.



•

Persistent Prefix IPv6 will provide the device with an IP address unique to 
that device that will remain with that device until the address is relinquished 
by the user (i.e., when the user moves the device off the Verizon Wireless 
network).



•

IPv4-only devices are not compatible with Persistent Prefix IPv6 addresses.

Re: CIA Exploits on Mikrotik Hardware /Software

[Tom Smyth]

Hello,
there were 2 typos on that maiil

1) I used lads (sorry force of habit)  was meant in the sense of
Gender Neutrality  as opposed to excluding ladies,

2) the sample firewall rules had a space missing with the wrong
address list name :/

I have corrected them below

On Wed, Mar 8, 2017 at 3:17 PM, Tom Smyth  wrote:
> -- Forwarded message --
> From: Tom Smyth 
> Date: Wed, Mar 8, 2017 at 3:02 PM
> Subject: CIA Exploits on Mikrotik Hardware /Software
> To: INEX Members Technical Mailing List 
>
>
Hello
>
> For MikroTik Users in the community there are apparently live exploits
> for MikroTik software  and apparently this was used by the CIA, if the
> tools are released in the wild  this would represent a significant
> threat to your ISPs for those of you who have MikroTik Routers with
> public IPs on them and if they are not adequately filtered,
>
> I would humbly suggest that you apply best practices and filter the
> management services  and disable any management services that you dont
> absolutely need,
>
> for further details please find the following
>
> More Details on the MikroTik CIA Exploits
> https://forum.mikrotik.com/viewtopic.php?t=119255
>
> you can disable un needed administration services in
> IP/services menu,
>
> and I would suggest filtering access to the management ports and
> disabling the web management interface altogether and disable ftp
>
> If you want to protect the Routers apply filters on the input chain of
> the Firewall Filter,
>
> tcp dstport 22 for ssh
> tcp dstport 8291 for winbox
> tcp dstport 23 for telnet
> tcp dstport 8729 api
> tcp dstport 8728 api
> tcp dstport 20,21 ftp
> be aware that the api interfaces could have been enabled if you were
> upgrading the software from an older version
>
>
> I have included a sample configuration script below just to help But
> make sure to adjust it to suit your own needs...
>
> /ip service
> set telnet disabled=yes
> set ftp disabled=yes
> set www disabled=yes
> set www-ssl certificate=cert1 disabled=yes
> set api disabled=yes
> set api-ssl disabled=yes
>
> /ip firewall address-list
> add address=5.134.88.0/29 list=Management
>
> #STOP REPLACE the address above with your management ip ranges
> #copy the lines to add more ips
>
>
>
> /ip firewall filter
> add action=accept chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=22
> src-address-list=Management protocol=tcp
> add action=accept chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=8291
> src-address-list=Management protocol=tcp
>
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=22 protocol=tcp
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=8291 protocol=tcp
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=23 protocol=tcp
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=21 protocol=tcp
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=8729 protocol=tcp
> add action=drop chain=input comment="Drop input Rule to protect
> MikroTik Devices" dst-port=8728 protocol=tcp
>
>
> after running that script on your mikrotik Firewall ensure the rules
> that you added are moved straight to the top of the firewall  rule set
> 
>
>
>
> it is important to note that full details on the exploits are not
> available but any service that Mikrotik is running could be an entry
> point so bear that in mind ,
>
> eg , NTP  DNS ...  Hotspot , CDP / MNDP / and the long list of VPN
> services that can be configured on MikroTik...
>
>
> --
> Kindest regards,
> Tom Smyth
>
> Mobile: +353 87 6193172
> -
> PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
> This email contains information which may be confidential or
> privileged. The information is intended solely for the use of the
> individual or entity named above.  If you are not the intended
> recipient, be aware that
> any disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this electronic
> transmission in error, please notify me by telephone or by electronic
> mail immediately. Any opinions expressed are those of the author, not
> the company's  .This email does not constitute either offer or
> acceptance of any contractually binding agreement. Such offer or
> acceptance must be communicated in
> writing. You are requested to carry out your own virus check before
> opening any attachment. Thomas Smyth accepts no liability for any loss
> or damage which may be caused by malicious software or attachments.



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
-
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
This email contains information which may be confidential or
privileged. The information is i

Fwd: CIA Exploits on Mikrotik Hardware /Software

[Tom Smyth]

-- Forwarded message --
From: Tom Smyth 
Date: Wed, Mar 8, 2017 at 3:02 PM
Subject: CIA Exploits on Mikrotik Hardware /Software
To: INEX Members Technical Mailing List 


Hi Lads,

For MikroTik Users in the community there are apparently live exploits
for MikroTik software  and apparently this was used by the CIA, if the
tools are released in the wild  this would represent a significant
threat to your ISPs for those of you who have MikroTik Routers with
public IPs on them and if they are not adequately filtered,

I would humbly suggest that you apply best practices and filter the
management services  and disable any management services that you dont
absolutely need,

for further details please find the following

More Details on the MikroTik CIA Exploits
https://forum.mikrotik.com/viewtopic.php?t=119255

you can disable un needed administration services in
IP/services menu,

and I would suggest filtering access to the management ports and
disabling the web management interface altogether and disable ftp

If you want to protect the Routers apply filters on the input chain of
the Firewall Filter,

tcp dstport 22 for ssh
tcp dstport 8291 for winbox
tcp dstport 23 for telnet
tcp dstport 8729 api
tcp dstport 8728 api
tcp dstport 20,21 ftp
be aware that the api interfaces could have been enabled if you were
upgrading the software from an older version


I have included a sample configuration script below just to help But
make sure to adjust it to suit your own needs...

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set www-ssl certificate=cert1 disabled=yes
set api disabled=yes
set api-ssl disabled=yes

/ip firewall address-list
add address=5.134.88.0/29 list=Management

#STOP REPLACE the address above with your management ip ranges
#copy the lines to add more ips



/ip firewall filter
add action=accept chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=22
src-address-list=Management_ipprotocol=tcp
add action=accept chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=8291
src-address-list=Management_ipprotocol=tcp

add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=22 protocol=tcp
add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=8291 protocol=tcp
add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=23 protocol=tcp
add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=21 protocol=tcp
add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=8729 protocol=tcp
add action=drop chain=input comment="Drop input Rule to protect
MikroTik Devices" dst-port=8728 protocol=tcp


after running that script on your mikrotik Firewall ensure the rules
that you added are moved straight to the top of the firewall  rule set




it is important to note that full details on the exploits are not
available but any service that Mikrotik is running could be an entry
point so bear that in mind ,

eg , NTP  DNS ...  Hotspot , CDP / MNDP / and the long list of VPN
services that can be configured on MikroTik...


-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
-
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
This email contains information which may be confidential or
privileged. The information is intended solely for the use of the
individual or entity named above.  If you are not the intended
recipient, be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic
transmission in error, please notify me by telephone or by electronic
mail immediately. Any opinions expressed are those of the author, not
the company's  .This email does not constitute either offer or
acceptance of any contractually binding agreement. Such offer or
acceptance must be communicated in
writing. You are requested to carry out your own virus check before
opening any attachment. Thomas Smyth accepts no liability for any loss
or damage which may be caused by malicious software or attachments.

Re: google ipv6 routes via cogent

[Alarig Le Lay]

On mer.  8 mars 09:29:11 2017, Marty Strong via NANOG wrote:
> I wouldn’t be surprised if that’s unwanted, where Telstra domestic is
> announcing to Telstra International, who in turn announces to Cogent.

I wouldn’t too, especially since I don’t see it anymore:
alarig@nominoe:~ % birdc6 show route for 2a00:1450:4001:811::2003
BIRD 1.5.0 ready.
2a00:1450:4001::/48 via 2a06:e040:3501:101:2::1 on em0.21 [bgp_quantic 
13:09:29] * (100) [AS15169i]
   via 2a00:5881:8100:ff00::142 on gre0 [bgp_arn_hwhost1 
2017-01-30] (50) [AS15169i]
   via 2a00:5884:ff::13 on gre1 [bgp_arn_hwhost2 2017-01-30] 
(50) [AS15169i]

And quantic now reaches them via HE.

-- 
alarig


signature.asc
Description: PGP signature

scalematrix network access

[Mark Stevens]

Good Morning,


Is anyone having access issues into sites within scalematrix.net network?
Our traces make it out of Cogent and into Level3 and either die in 
Level3 or a couple hops past Level3 into scalematrix.net network.


If someone from Scalmatrix or Level3 reads this, can you email me 
offline to discuss?



Thanks

Mark

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

On 08-03-2017 00:27, Dennis Bohn wrote:


In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.

AFAICT, Cisco V6 HSRP (mentioning that brand only because it caused me to
try to figure something out, a coincidence that this is in reply to Jakob
from Cisco but is based on what he wrote)  relies on Link Local addresses.
I didn't understand why link locals should be there in the first place
seemed klugey and have googled, looked at rfcs and tried to understand why
link local addresses were baked into V6. The only thing I found was that it
enabled interfaces on point to point links to be unaddressed in V6. (To
save address space!??) Can anyone point me in a direction to understand the
reasoning for link local addressing?

dennis


Many features of IPv6 depends on link local. Take a look at the routing 
table of your computer - you will find that most routes have a next hop 
with a link local address. Many buildin protocols, such as RA and 
DHCPv6, use link local to communicate without depending on any 
configuration.


Many protocols with automatic discovery will use link local - why would 
you want your printer or local NAS server to use a public IP when link 
local works? In fact, you may prefer the printer to be only on link 
local so it can not be accessed from outside. The public IP is something 
your ISP assigns to you, so using that unnecessary only makes your setup 
vulnerable to problems if the internet is down. You could assign an ULA 
prefix https://en.wikipedia.org/wiki/Unique_local_address for your 
network but most people wont.


Regards,

Baldur

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

EZIP has no transition strategy and is not backwards compatible with 
IPv4. The scheme is unworkable.


It is not possible to dual stack EZIP because it pretends to be IPv4.

The author of EZIP should demonstrate a working prototype. We need to 
see a setup with two clients on a shared external IP address. Then 
demonstrate that the clients can access an EZIP enabled site and also 
that the clients can access unmodified IPv4 sites such as Google.com and 
Facebook.com.


The later test will fail and there is no fix. EZIP requires a big bang 
transition where the whole world implements EZIP on the same day.


EZIP embeds extra address information in IP option headers. The remote 
site needs to take that extra address information and send back in the 
replies. The remote site needs to read the extra "source EZIP" option 
header and put that as an "destination EZIP" option header on reply 
packets. Legacy IPv4 sites do not know the meaning the extra option 
headers and can not do send them back. Packets will arrive at the EZIP 
gateway without option headers. The EZIP gateway will have no option 
other than to drop the packets, because without option headers nothing 
will differentiate the multiple clients behind the gateway.


The EZIP gateway could fall back to NAT when the remote site does not 
have EZIP support. However no method is provided that can tell the EZIP 
gateway wether the remote has EZIP support or not. Since the EZIP 
gateway works on the IP level, we can not use some DNS tricks like 
NAT64/DNS64.


Regards,

Baldur


On 07-03-2017 18:46, Jakob Heitz (jheitz) wrote:

1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f.

Some higher layer protocols embed IP addresses into their data.

These points make changing IP so difficult.

In addition, IPv6 has link local addresses.
This one seemingly insignificant detail causes so much code churn
and is probably responsible for 10 years of the IPv6 drag.
Thakfully, site local was deprecated.

Thanks,
Jakob.


Date: Mon, 6 Mar 2017 22:00:45 +0100
From: Baldur Norddahl 
To: nanog@nanog.org
Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
Message-ID: <5645714e-e468-4655-34cf-6e70aa7cf...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

That proposal is far too wordy. Here is the executive summary:

Encode extra address bits in extension headers. Add a network element
near the destination that converts such that the destination IP of a
packet to IP a.b.c.d with extension header containing e.f is translated
to 192.168.e.f. In the reverse direction translate source address
192.168.e.f to a.b.c.d and add option header with e.f.

Executive summary end.

As far as I can tell, the only advantage of this proposal over IPv6 is
that the network core does not need to be changed. You could communicate
with someone that had an EZIP address regardless that your ISP did
nothing to support EZIP.

The disadvantage is that every single server out there would need to be
changed so it does not just drop the option headers on the reply
packets. All firewalls updated so they do not block packets with option
headers. All applications updated so they understand a new address format.

Servers and applications could also confuse TCP or UDP streams that are
apparently from the same source, same port numbers, only thing that
differentiates the streams is some option header that the server does
not understand.

The customers of the ISP that deploys EZIP would not need to update
anything (unless they need to communicate with other poor souls that got
assigned EZIP addresses), however everyone else would. This is not a
good balance. The customers would experience an internet where almost
nothing works. It would be magnitudes worse than the experience of an
IPv6 only network with NAT64.

It is a fix for the wrong problem. Major ISPs have IPv6 support now. It
is the sites (=servers) that are lacking. If Twitter did not deploy IPv6
why would you expect them to deploy EZIP? Why would some old forgotten
site with old song texts in some backwater country somewhere?

We already have better solutions such as CGN with dual stack, NAT64,
DS-Lite, MAP etc.

None of that is discussed in the RFC. Is the author aware of it?

Regards,

Baldur

Re: google ipv6 routes via cogent

[Marty Strong via NANOG]

I wouldn’t be surprised if that’s unwanted, where Telstra domestic is 
announcing to Telstra International, who in turn announces to Cogent.

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

> On 8 Mar 2017, at 07:18, Alarig Le Lay  wrote:
> 
> On sam. 25 févr. 09:49:56 2017, Aaron wrote:
>> Hi, I'm new to the nanog list, hope this isn't out of scope for what is
>> usually discussed here.
>> 
>> 
>> 
>> Cogent is telling me that I can't route through cogent to get to google ipv6
>> routes (particularly the well known dns addresses 2001:4860:4860::88xx)
>> because google decided not to advertise those route to one of their mutual
>> peers.
>> 
>> 
>> 
>> Anyone know anything about this ?  .and why it happened and when it will be
>> resolved ?
>> 
>> 
>> 
>> -Aaron
> 
> Hi,
> 
> Since this morning, I see again google routes from cogent:
> https://paste.swordarmor.fr/raw/wnFQ
> 
> But, with very bad latency. To go from Rennes (France) to Frankfurt
> (Germany), it transits via Sydney, and still thought other ASes:
> https://paste.swordarmor.fr/raw/PlSM
> 
> -- 
> alarig