Although I’m not familiar with your network deployment and this router solution (Mikrotik) it looks indeed that the different “sniffer” capabilities for CALEA are very similar to what is needed for European Lawful Interception. Especially the “sniff-id” which seems to allow the interception of the packet stream of a specific user. I think it’s better to intercept the target’s traffic at the source of the interception instead of intercepting a whole packet stream and perform the screening of the target traffic later. It will probably save you some internal bandwidth.
Where this solution differs is that they use the US-based ATIS standards “Content delivery to LEA according to ATIS-1000013.2007 (Lawfully Authorized Electronic Surveillance For Internet Access and Services)” while in Europe we use the ETSI standards for the delivery of the intercepted packet stream. The principles are very similar. For instance what ATIS calls “Call Content Connection” (CCC) in Europe we call it “Content of Communication” (CC). I must note that our Law Enforcement Monitoring Facility (LEMF) is based on the ETSI standards and does not support the US-based ATIS standards.
Therefore, in our case the target’s packet stream that is intercepted should be delivered according to the ETSI specifications (ETSI TS 102 232-1 and ETSI TS 102 232-3).
However, as a first step I would suggest to try to intercept internally some traffic of a test target user and see whether the whole packet stream is correctly intercepted in your router or CMTS. Even when the target access changes its IP address in case of new IP address lease for instance.
As a second step you may ask Mikrotik whether they have a version of their capabilities that support the above mentioned ETSI specifications instead of the US-based ones.
Just for information and to elaborate a bit on the ETSI specifications, I provide you below an example of a decoded structure how an IP packet should be delivered to our LEMF according to the ETSI specifications TS 102 232-1 and TS 102 232-3. It may appear a bit complex at first sight…
Here are some explanations of these ETSI fields and parameters:
These first parameters form the “header” and is based on the ETSI TS 102 232-1 specification.
li-psDomainId OBJECT IDENTIFIER = {itu-t(0) identified-organization(4) 0 2 2 5 1 15}
Specifies the domain ID and version of the ETSI TS 102 232-1 → here version 15.
lawfulInterceptionIdentifier LawfulInterceptionIdentifier = 32.30.31.36.30.34.30.33.30.37.32.39.39.33.30 [201604030729930]
The LIID is a 15 digits identifiers that is sent to you in the interception order from ÜPF. The LIID is unique per target.
authorizationCountryCode PrintableString = “CH”
The country code is always “CH” → fix value
operatorIdentifier OCTET STRING = 39.39.39.39.39 [99999]
This Operator identifier is a 5 digits and is provided to you by ÜPF. → fix value
networkElementIdentifier OCTET STRING = 31.39.31.2e.31.36.38.2e.31.33.39.2e.32.31 [191.168.139.21]
This is the ip address of your network element and depends on your implementation.
communicationIdentityNumber INTEGER = 1371635704
This Communication Identity Number is set by your equipment. It is unique by communication session. (see also ETS ITS 102 232-1 clause 5.2.4)
deliveryCountryCode PrintableString = “CH”
This is always “CH” → fix value
sequenceNumber INTEGER = 12358
This sequence number is incremented by one for every IP packet sent. (see also ETS ITS 102 232-1 clause 5.2.5)
timeStamp GeneralizedTime = “20160424061205.895Z”
Time stamp when the header has been created. Preferably in UTC.
Parameters based on the ETSI TS 102 232-3 specification for the IP access
iPCCObjId RELATIVE-OID = {5 3 9 2}
Specifies the relative domain ID and version of the ETSI TS 102 232-3 → here version 9.
iPPackets OCTET STRING = 45.00.01.48.d4.3b.00.00.3f.11.f3.a1.51.0d.ef.ec.d5.dd.9b.f0.etc…
This is one IP packet (IPv4) that has been intercepted.
So Mikrotik should make a statement.