Difference between revisions of "OpenLI Test Cases"
(Created page with "=OpenLI Test Cases= Some ideas about what to test and how. * Start with an intercept for a client that is doing nothing (not even on-line) - ensure nothing is delivered to t...")
Revision as of 08:18, 11 November 2019
OpenLI Test Cases
Some ideas about what to test and how.
- Start with an intercept for a client that is doing nothing (not even on-line) - ensure nothing is delivered to the LEA
- Highlevel - do 90% of testing with http / un-encrpyted content.
- Start with IPv4 (once all the content test cases are working correctly move on to IPv6)
- Capture the clients interface, Servers interface - ensure the reconstructed packets match.
- Create a website that 'you control' that generates 'dynamic content' each time its visited, such as webpage with theEPOCH timestamp, or an image or test file of which the download filenames re-generate each visit to ensure the content is delivered to the client and is not being cached.
- Cksum the files, what is downloaded should be what is intercepted
- ICMP tests / pinging
- Use wget and curl (again to remove any browser caching induced issues)
- Keep under 1400 MTU on the client until things are re-constructing correctly
- Slowly move the MTU rate from up from 1400 - 1500 (till you see packets fragmenting) - Ensure that there is no fragmentation between the interception point and the collector. (IE drop the MTU rate at the client and the intercept it complete, increasing the clients MTU rate and the intercept gets patchy)
- Filter the intercepted content, ensure that only content from the client is provided.
- Take note of the clients IP and what is seen at the server, ensure this matches the CC/Content and the IRI, Note if the client is behind CGNAT IRI will match the client however the server will see the public IP which is not supplied in the IRI.
- Once content is being delivered, move to IRI testing, Start with the client 'offline', have the client go 'online' ensure an IRI start record is generated, (In a mobile context there may be multiple - IE 3G (UMTS) Circuit Switched and LTE/4G (EPS) IP Data parts of the network.
- Check with the RSP, how often are accounting records being generated (10mins -> 1 hour is common), ensure an IRI continue record is created for each.
- Disconnect the client, within one accounting period a IRI Stop record should be generated
- Setup two LEA handovers (pretending to be two different LEAs), create one intercept per LEA Handover for the same target - start one several hours after the other. Ensure content and IRI is delivered, ensure that stopping or suspending one intercept doesn't affect the other
- Specify that an intercept ends at time x and ends at time y, validate that IRI and CC is starts being delivered after x and nothing is delivered after time y.
- If enabled, ensure the keepalive packets are being sent at the correct interval (when nothing is coming over the handover) and being responded to correctly.
http://ipv6ready.me/ use to validate the client, not really for intercept testing
http://nsx.de Provides the clients IPv4 or IPv6 address they connected from
wget -O index.html -4 nsx.de
wget -O index.html -6 nsx.de