[nznog] Affordable TICSA LI Solution and Support

[brianparsons]

We are Telecom Forensics, an OEM of LI solutions based on the Kapiti Coast. 
�
Being an OEM, there are no 'middle men' to inflate the price. We can 
provide a drop-in LI system that is fully supported, local and affordable.
�
We are proven LI Systems experts operating since 2005. We have deployed 
with national providers and on many complex projects both cellular and fixed. 
ASN.1 and ETSI Standards is what we do all day, everyday. Our projects and 
experience are detailed on out website:
www.telecomforensics.com.   �
Our Costs and Deliverables:
We supply the complete turnkey solution for your TICSA regulatory 
compliance.
No minimum contract term, full 24/7 support is provided.
�
Costs

One off: Upfront $5K Signup Fee - covers design, 
integration, pre-production testing and systems training,
Monthly: Starting at fixed $5K lease cost per month. 
For industry fairness the monthly charge is scaled to the number of subscribers.

​ *** SPECIAL OFFER ***: 10% discount on the monthly lease if you sign-up 
within the next four weeks!� Contact us via our website forms, 
https://www.telecomforensics.com/. ��  Annual contracts are also available. 
Contact us to discuss your requirements.
�
Deliverables

A working pre-production environment; Provisioning, (HI 
2/3) ASN.1 correct, complete & ready to cut-over to LEA Test then eventually 
LIVE.
Training on the LI system in parallel with LEA 
validation/testing HI 'usable format' pre-production delivery.
Training (provisioning and alarms) to meet the 'always 
ready' requirement of the TICSA Act.
Support: The monthly fee includes Layer 3 support.� 
TFE Solution License and Support Contract to meet Service Level 
Agreements of the TICSA solution
Once you have Agency sign-off to switch to their LIVE environment, you 
can get back to your core business activity.
Time Frame: Depending on the size of the network, this could take one 
to two weeks after sign-up.   �
Custom interface work is available including any OEM TIER 4 Code level 
support. POA.�
TFE offers affordability for a trusted and reliable LI solution.
�
We welcome your enquiry through our web forms, 
https://www.telecomforensics.com/,


kind regards

Brian Parsons BE(E&EE) MIEE | CEO TFE | +64272987097


www.telecomforensics.com

___

Some technical detail:

Our systems operate an exokernel with optimised LI ASN.1 and protocol 
firmware on the Network (NWO) traffic inputs.

The NWO interface work independent of main OS for speed and security 
and line rate processing (at any packet size).

We support the following line interfaces: GE, 10G, 40G scaled to 100G, 
and typically can receive from any newtork tap/mirror port, splitter.

The probe throughput (XI fwd rate) after processing is wire speed with 
capacity per interface of 1.1 million

sessions per gig of installed Mem. Typical System interfaces: GE NWO, 
GE XI/OAM, GE HI.


___

�
___
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog

Re: [nznog] Affordable TICSA LI Solution and Support

[brianparsons]

Hi Nathan,We dont work with the NSA, and you dont need them to decrypt mobile 
data there are many keys used in a heirachy depending on the pairing mobile
nodes eNB/UE/MME/HSS etc, you just need to be on the right interface to catch 
and process the exchange Control/User Plane (keys vary) is trivial for LI 
vendors like myself who carry key derivation/enc/dec logic and protocol 
sequencing to handle such an exchange. eg UE/HSS:CK,IK - a well known
mapping is your USIM/AuC:K. As far as knocking on doors, yes absolutely 
probably me, i sell and support what I build and proud of it, but NSA lol, but 
we sell more off shore -
why is that?My post was only intended to inform of a local option that could 
make a material difference to operators trying to meet their obligations under 
the ACT.As an LI provider i have met a couple of your members stung badly after 
signing offshore and we couldve helped them, also i was encouraged by the LEAs 
that
speak at your conference - they obviously cant directly endorse but the spirit 
and intention of my post was not to offend just inform. TFE like most LI 
vendors do not advertise
or market, and there are only a handfull of us OEMs that build LI solutions the 
rest are reseller middle men.As far as OpenLI free it is your developing, thats 
great but till then compliance is real, but we wish you all the best. 2050 is 
when you'l have enough field experience in CU/FIbre/hardware with ASN.1 + 
ETSI/CALEA at working at single thread code level. Lets say you do cobble 
something together before then - once you can
multithread your kernel (tuplet flows) linerate 200g (64B) stream + LI let me 
know, sorry lets make it easy - start with GE @ 1.44 Mpps + LI and ASN enc over 
HI => garauntee you a DoS all day and dont even think about SLAs. But good luck 
with that, until then TICSA 2017�The point is LI is not just about about 
Software. Hardware, firmware and real world field experience is
required - how do you handle FEXT/NEXT on upstream active/passive TAPs can you 
run in rx only given the requirements and restrictions on spurious noise and 
traffic, there are many tech and capability requirements of the probe/mf which 
ETSI Parts are you going to do first?. HA/asymmetric network
deployments (non-collo paths), how will you handle this situ? and TIER 4 
support on commercial fabrics (Open generally means zip support - so i geuss 
nothing is realtime). If you do all this how will you be able to demonstrate at 
any point in time the two core aspects of TICSA 'format
usability' and 'nw readiness'.We do LI not 'network security', ie. we build the 
'device' and MF as descirbed
in the NZ Search and Surveillance Act 2012 and NZ TICSA 2017.regardsBrian 
Parsons BE(E&EE) MIEE | CEO TFE | LI TICSA SIGINT�cheers

 Original Message 

Subject: Re: [nznog] Affordable TICSA LI Solution and Support

From: "Nathan Ward" 

Date: Wed, June 27, 2018 10:06 pm

To: brianpars...@subpico.com

Cc: nznog@list.waikato.ac.nz

--



>

>> On 27/06/2018, at 11:45 AM, brianpars...@subpico.com wrote:

>>

>> We are Telecom Forensics, an OEM of LI solutions based on the Kapiti Coast.

>>

>> Spam spam spam

>

> Are you the chap from Kapiti who a few years ago was knocking about claiming 
> that the NSA had given him some sort of secret codes to magically decrypt all 
> mobile data, or was that someone else?

>

> Not too sure why you’d be pushing this here, when there’s a 
> community effort to develop something open source and free.
I’m looking forward to where the OpenLI project goes, and I’d 
suggest that anyone looking for LI tools look towards the OpenLI project, which 
has
been discussed on this before, and at the NZNOG conference, and I believe will 
be discussed tomorrow at the NZIX AGM.
> ps. It’s free, but, go support it with some $, it’ll still be 
> cheaper than commercial solutions.

>

> NZ: Highest per capita ETSI compliant LI implementors in the world.

>

> How long before Fincham pops up saying “oh also there’s an OpenLI 
> project you should look at”? Place your bets.

>

> Looking forward to laughing about this one over drinks tomorrow night.

>

> --

> Nathan Ward

>

>
___
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog

Re: [nznog] Affordable TICSA LI Solution and Support

[brianparsons]

Hi Shane,
I appreciate your response and it sounds like you and the OpenLI team making 
great progress, i wish the project and deployments all the best. Writing packet 
capture isnt hard and anyone with a compiler can do it. Of course a little 
coding b/gnd helps and depending on what your
trying to do, the level of hardware knowhow you need.
Take 100% packet capture - 'shouldnt' be a problem at a constant 1 pps, but it 
will be if you take 2 s to process. Lets say you optimize hw down .5 s with a 
DAG (i worked their native's ~2004) your still not going to make it.
Timing values are too ilustrate my point and my take away from you response is 
OpenLI is basically targeting the general usecase here in NZ where say GE or 
10G ~50/60 pk. % link utilization is still pretty OK and fit-for-purpose. I 
assume here your OpenLI app (NWO->IAF/MF ASN.1Enc/MD->HI) is
well optimized from your excellent experience too. One suggestion maybe to 
bench it with XIA/Spirent STC for thruput vs line-rate/packet sizes vs expected 
from NOC. I dont use cap libraries or anything like that myself, my 
arch/interface is very different in exo/no net_dev, zero intr,dis flow
handling depending on the ICs i got on hand (i have a french foreign legion 
policy for hardware - survive the bench and your in ). LI started here in NZ 
but was taken to another level in the US with massive linerates and volumes - 
vetting starts with corner case burntests, sinking IPGs <9.7ns ..<.97ns (100G+) 
with 1 Target frame - and if you can catchit send try to send that 1 frame, 
only after that you get to do something usefull and process it. Sounds easy as
you can appreciate back in the day with north/south PCIE this was a massive 
feat, no SoCs root/pcie qpi we have today.
Obviously this level of performance is bit OTT for our general LI small ISP 
market, but data volumes aint gonna go down - cheers for the heads up. Again 
wish you and the
OpenLI project team much success.
regards
Brian Parsons BE(E&EE) MIEE | CEO TFE | LI TICSA SIGINT
 Original Message 
Subject: Re: [nznog] Affordable TICSA LI Solution and Support

From: "Shane Alcock" 

Date: Fri, June 29, 2018 2:38 pm

To: brianpars...@subpico.com

Cc: nznog@list.waikato.ac.nz

--



> Hi Brian, all,

>

> As the primary developer on the OpenLI project, I've been asked to address

> some points that you've raised and correct any misconceptions people might

> have about OpenLI as a result of this thread.

>

> For anyone concerned about a possible lack of experience in writing packet

> capture software, most of my 14 years working here at the WAND network

> research group has been dedicated to both writing and running software for

> high speed passive capture and analysis projects. I am one of the primary

> authors and maintainers of libtrace [1] [2], which is widely used both in

> academia and industry (as well as the OpenLI software itself). Libtrace

> supports a variety of capture methods and hardware, including DAG and DPDK,

> and has a parallel API for writing multi-threaded packet capture

> applications, so I have a reasonable understanding of what is required of

> both hardware and software to do high-rate packet capture and encoding.

>

> OpenLI is not offering a "complete" solution to your TICSA problems. We

> provide software that can capture packets and convert them into ETSI

> records, wrapped in a centralised provisioning system for managing

> intercepts, along with a mediation function that will push the resulting

> records to the appropriate agency. Integration of OpenLI into your network

> is a matter for the operator; however, we have been working closely with

> the organisations that responded to our initial requests for funding to get

> their deployments up and running.

>

> Longer term, we are starting to have conversations about what support

> models we want to provide in the future, especially after the feedback I

> received at the NZIX AGM last night, so watch this space. WAND has a long

> history of maintaining and continually improving any open-source software

> that it has released to the public [3] even when it is no longer

> specifically funded by our research income (libtrace being a prime

> example), so if OpenLI is being used then you can anticipate that WAND will

> continue to look after it.

>

> Finally, the core software components of OpenLI are getting close to

> complete. We have provisioning, mediation, multi-threaded and

> multi-input-interface distributable collectors. We have support for voice

> intercept (SIP + RTP + RTCP) and support for standard IP intercept (RADIUS

> + IPv4), with IPv6 and static IP range intercepts not too far away. Most of

> the upcoming effort is focused on getting test deployments working within

> our partner networks, throwing "real" traffic at them and squashing any

> is

Re: [nznog] Affordable TICSA LI Solution and Support

[brianparsons]

55MPS will give max ~ 28G << 100G thruput @prema+sdf+64B+ifg. In the other 
direction, at 100G, with ave 512B your max is 20-25Mpps, in any case 40G is 
fine and you save
your firms $ on the 100G. Actually line capture at these speeds and thruputs 
have been doable for a good while now, mutli-Tbps is the challenge now. 
Capture/Filtering and processing are actually two different but interdependent 
things, as you know speed/thruput are normally qualified in terms
of packet sizes and app, nic profile:sustained/peak, For capture, L3 ACLs 
segment work etc its just fixed and static filtering; different to triggers 
which need higher state protocol/flow processing, db lookups, markov etc, alot 
more smarts and CPU CS this lowers the upper limit. CPU stats will be
very different.
regards
Brian
 Original Message 

Subject: Re: [nznog] Affordable TICSA LI Solution and Support

From: Joel Wirāmu Pauling 

Date: Sat, June 30, 2018 12:40 pm

To: brianpars...@subpico.com

Cc: "Shane Alcock" 

"nznog" 

--



> You can achieve 55MPS from the latest generation of Smartnics - enough to

> do 100GBits ports, with Layer3 ACLs ; with almost no CPU overhead. This is

> running pretty much Mainline Linux (with Vendor Specific Smartnic offloads

> i.e ASAP2 (mellanox), or Netronome). You then obviously need to dump it

> somewhere but with some NVMEE Cards on x8 Bus you can do that too - before

> shuffling it to slow and cheap archival.

>

> So ; no you don't need any real hardware smarts to do this today, there is

> off the shelf bits you can add to off the shelf x86 hardware. Just a little

> planning of your Capture box hardware and knowing what NIC's to use.

>

> -Joel

>

> On 30 June 2018 at 11:39,  wrote:

>

>> Hi Shane,

>>

>> I appreciate your response and it sounds like you and the OpenLI team

>> making great progress, i wish the project and deployments all the best.

>> Writing packet capture isnt hard and anyone with a compiler can do it. Of

>> course a little coding b/gnd helps and depending on what your trying to do,

>> the level of hardware knowhow you need.

>>

>> Take 100% packet capture - 'shouldnt' be a problem at a constant 1 pps,

>> but it will be if you take 2 s to process. Lets say you optimize hw down .5

>> s with a DAG* (i worked their native's ~2004)* your still not going to

>> make it. Timing values are too ilustrate my point and my take away from you

>> response is OpenLI is basically targeting the general usecase here in NZ

>> where say GE or 10G ~50/60 pk. % link utilization is still pretty OK and

>> fit-for-purpose. I assume here your OpenLI app (NWO->IAF/MF

>> ASN.1Enc/MD->HI) is well optimized from your excellent experience too. One

>> suggestion maybe to bench it with XIA/Spirent STC for thruput vs

>> line-rate/packet sizes vs expected from NOC. I dont use cap libraries or

>> anything like that myself, my arch/interface is very different in exo/no

>> net_dev, zero intr,dis flow handling depending on the ICs i got on hand (i

>> have a french foreign legion policy for hardware - survive the bench and

>> your in ). LI started here in NZ but was taken to another level in the US

>> with massive linerates and volumes - vetting starts with corner case

>> burntests, sinking IPGs <9.7ns ..<.97ns (100G+) with 1 Target frame - and

>> if you can catchit send try to send that 1 frame, only after that you get

>> to do something usefull and process it. Sounds easy as you can appreciate

>> back in the day with north/south PCIE this was a massive feat, no SoCs

>> root/pcie qpi we have today.

>>

>> Obviously this level of performance is bit OTT for our general LI small

>> ISP market, but data volumes aint gonna go down - cheers for the heads up.

>> Again wish you and the OpenLI project team much success.

>>

>> regards

>>

>> Brian Parsons BE(E&EE) MIEE | CEO TFE | LI TICSA SIGINT

>>

>>  Original Message 

>> Subject: Re: [nznog] Affordable TICSA LI Solution and Support

>>

From: "Shane Alcock" 

>> Date: Fri, June 29, 2018 2:38 pm

>> To: brianpars...@subpico.com

>> Cc: nznog@list.waikato.ac.nz

>> --

>>

>> > Hi Brian, all,

>> >

>> > As the primary developer on the OpenLI project, I've been asked to

>> address

>> > some points that you've raised and correct any misconceptions people

>> might

>> > have about OpenLI as a result of this thread.

>> >

>> > For anyone concerned about a possible lack of experience in writing

>> packet

>> > capture software, most of my 14 years working here at the WAND network

>> > research group has been dedicated to both writing and running software

>> for

>> > high speed passive capture and analysis projects. I am one of the primary

>> > authors and maintainers of libtrace

Re: [nznog] Comcom/Samknows broadband testing from a different perspective

[brianparsons]

OpenWRT/LEDE binary, Just shell on.. opkg update, -i what you need..., netstat 
-antop | grep EST this will surprise you, dest will surprise you more then I� 
put in the green wheely.� On the WAN link you may see lots of src privates 
indicating typical dinky rtr/fw nat not coping
similarly actual/true $paid for bandwidth at src (home) = rubbish + legit 
flows. rubbish flows (in/out) of breaks packet concurrency increasing delays 
and maxin out (netflix/gaming stream) PDVs on clients - recommend filter|block 
upstream of router will lead to a huge improvement in media quality
and performance of your home router.
good luck - regards brian
 Original Message 

Subject: Re: [nznog] Comcom/Samknows broadband testing from a different 
perspective

From: "Peter Lambrechtsen" 

Date: Thu, September 27, 2018 4:37 pm

To: brian.c...@waikato.ac.nz

Cc: "NZNOG" 

--



> There is a Geekzone thread that I kicked off when I attended the Commerce

> Commission presentation about Samknows and got to meet Sam.

>

> https://www.geekzone.co.nz/forums.asp?forumid=49&topicid=237852

>

> I've done a bit of analysis on the traffic but haven't dug too deep yet as

> I didn't want to bust open the box and try and reverse engineer their

> OpenWRT build.

>

> Happy to put anyone in touch with the guys I have dealt with directly from

> the Comcom and Samknows too.

>

> On Thu, Sep 27, 2018 at 12:59 PM Brian Cole 

> wrote:

>

>> Acknowledged with thanks,

>>

>> Brian

>>

>> On Thu, 27 Sep 2018 at 12:58 PM, Nathan Ward  wrote:

>>

>>> Hi Brian,

>>>

>>> You should call their support if you think there’s something going on

>>> that’s impacting your connection.

>>>

>>> They will detect if your connection is in use and doing more than (I

>>> think) 64kbit/s in the last 30s or something, and won’t run the tests.

>>>

>>> They have some clever stuff to detect if your wifi is in use, without

>>> being connected to your network and without being your AP. Perhaps 
>>> that’s

>>> playing up?

>>>

>>> Pretty sure it’s publicly documented, check out the links in that

>>> original post and if not we can dig up some other stuff I’m sure.

>>>

>>> On 27/09/2018, at 11:38 AM, Brian Cole  wrote:

>>>

>>> Hi all,

>>>

>>> Longtime listener; first time caller.

>>>

>>> I signed up to SamKnows (partly out of curiosity and partly so I can have

>>> hard data about my connection that I pay for) at home.

>>>

>>> Over the last week my connection has gone from slightly adequate with the

>>> occasional drop out to a slow connection with regular drop outs.

>>>

>>> Netflix and YouTube are stuttering, video games drop connection, and

>>> websites hang at random times.

>>>

>>> I can't help but think that the email shared by Dylan sheds some light on

>>> why that maybe.

>>>

>>> This programme won't be terribly successful if everyone gets sick of

>>> having a terrible connection during peak hours and shuts the white box

>>> down.

>>>

>>> Pretty frustrating.

>>>

>>> Brian

>>>

>>>

>>>

>>> --

>>>

>>> *Brian Cole* */** Research Projects Developer*

>>> *Research & Enterprise **/** Research Office **/** University of

>>> Waikato*

>>> *Private Bag 3105* */* *Hamilton 3240* */*

>>> *New Zealand**www.waikato.ac.nz*  */*

>>> *mob + 64 21 049 9183**email brian.c...@waikato.ac.nz

>>>  *

>>>

>>> ___

>>>

>>>

>>> NZNOG mailing list

>>> NZNOG@list.waikato.ac.nz

>>> https://list.waikato.ac.nz/mailman/listinfo/nznog

>>>

>>>

>>> --

>> Please excuse any brevity, spelling mistakes, or errors in this email due

>> to being sent from a mobile device.

>> ___

>> NZNOG mailing list

>> NZNOG@list.waikato.ac.nz

>> https://list.waikato.ac.nz/mailman/listinfo/nznog

>>

> ___

> NZNOG mailing list

> NZNOG@list.waikato.ac.nz

> https://list.waikato.ac.nz/mailman/listinfo/nznog

>
___
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog